每一位后端工程师dou曾遭遇过那种令人抓狂的时刻：明明代码逻辑严丝合缝，明明加了kan似坚不可摧的分布式锁，生产环境的数据库里却依然出现了诡异的“负库存”或者“余额覆盖”。这就像是你明明锁上了家门，小偷却依然Neng在你眼皮子底下把家具搬走。

Zui近，在一次对核心资产系统进行高并发压测的过程中，我就撞上了这堵墙。场景并不复杂：账户余额100元，线程A扣减10元，线程B也扣减10元。按理说无论怎么并发，Zui终结果应该是90元。然而现实狠狠地给了我一巴掌——系统里竟然出现了80元的余额。这不仅仅是数字的偏差，geng是对技术自信心的打击。

经过一番抽丝剥茧的排查，我终于发现那个隐藏在Spring AOP代理机制与锁释放时机之间的“幽灵”。今天我们就来聊聊这个让人防不胜防的陷阱，以及如何构建真正的纵深防御体系。

一、 那个kan似无懈可击的“伪代码”

在深入原理之前，我们先来kankan那段“出事”的代码。坦白讲，这段代码在hen长一段时间里dou被我们视为教科书级别的范例。它遵循了Zui朴素的编程哲学：先拿锁，再干活，Zui后释放锁。为了确保数据的一致性，我们还贴心地加上了Spring的声明式事务注解 `@Transactional`。

// ❌ 存在隐患的代码逻辑
@Transactional
public void decreaseAsset {
    String lockKey = "LOCK:ASSET:" + id;
    // 1. 获取分布式锁
    redisLock.lock;
    try {
        // 2. 查询当前余额
        Account account = accountDao.selectById;
        // 3. 内存计算并geng新
        long newBalance = account.getBalance - delta;
        if  throw new BusinessException;
        account.setBalance;
        accountDao.updateById; // 执行 SET balance = #{newBalance}
    } finally {
        // 4. 释放锁
        redisLock.unlock;
    }
}
// 🚩 这里的坑：事务其实是在方法结束后才提交的

乍一kan，这代码简直完美。`finally` 块保证了锁一定会释放，`@Transactional` 保证了数据库操作要么全Zuo要么全不Zuo。hen多资深开发可Nengdou写过类似的逻辑，甚至现在正在运行的系统中，这段代码可Neng就在“裸奔”。

但问题究竟出在哪？

二、 致命的时序差：锁释放了事务还没提交

要理解这个Bug，我们需要把视角从代码逻辑层面拉高到Spring框架的运行机制层面。这里的核心矛盾在于：锁的生命周期与事务的生命周期不一致。

我们dou知道，`@Transactional` 是基于 Spring AOP实现的。当你调用这个方法时Spring 会通过代理模式，在方法执行前开启数据库事务，在方法执行结束后提交事务。

请注意这个“执行结束后”。让我们把时间轴拉长，kankan线程A和线程B究竟发生了什么：

线程A 抢到了锁，进入方法。

线程A 执行业务逻辑，计算出新余额，执行 `updateById`。

线程A 走到 `finally` 块，释放锁。

此时致命的空档出现了！ 锁虽然释放了但 Spring AOP 的事务提交逻辑还没来得及执行。

线程B 此时正好请求过来发现锁Yi经空闲，于是顺利拿到锁。

线程B 执行查询操作。由于数据库的隔离级别通常是 Read Committed或 Repeatable Read，而线程A的事务还没提交，所以线程B读到的依然是旧数据！

线程B 基于旧数据计算余额，并执行geng新。

线程A 的事务终于提交。

线程B 的事务随后提交。

结果就是线程B的geng新直接覆盖了线程A的修改。这就是典型的“丢失geng新”问题。在分布式环境下这几十毫秒甚至几微秒的空档，足以让上千个请求穿透你的防御，造成数据错乱。

三、 深入Redisson：分布式锁的底层博弈

在解决这个问题之前，我们有必要先回顾一下我们手中的武器——Redisson，究竟是如何实现分布式锁的。毕竟Ru果连锁的原理dou搞不清楚，修修补补也只是治标不治本。

1. Redisson的加锁原理

Redisson并没有简单地使用 `setnx` 命令，而是利用了Lua脚本的原子性。当你调用 `lock` 方法时Redisson客户端会向Redis服务端发送一段复杂的Lua脚本。这段脚本的核心逻辑是：判断“锁”对应的key是否存在。Ru果不存在则进行设置，并设置过期时间，同时返回成功；Ru果存在则返回失败。

这里用到了Redis的哈希数据结构来存储锁的信息，比如持有锁的线程ID和重入次数。这种设计不仅保证了加锁和设置过期时间的原子性，还天然支持了可重入锁的特性。

2. kan门狗机制

hen多同学会问：“Ru果锁设置了30秒过期，我的业务跑了31秒怎么办？” Redisson早就想到了这一点。它引入了一个“kan门狗”机制。当你加锁成功但没有指定leaseTime时kan门狗会后台启动一个定时任务，每隔默认10秒检查一下Ru果持有锁的线程还活着，就重新刷新key的过期时间。

这确实解决了业务执行时间过长导致锁意外过期的问题，但也带来了新的隐患：Ru果业务逻辑卡死，这把锁可Neng永远不会被释放，直到客户端崩溃。这也是为什么我们一定要结合实际的业务耗时合理评估锁的超时时间。

3. 源码中的Lua脚本

虽然本文不贴大段源码，但我们需要理解那个Lua脚本的本质。它不仅仅是 `setnx`，它geng像是一个裁判，在Redis这一端确保了“判断”和“赋值”这两步动作中间不会被其他指令插队。这种基于Redis单线程模型实现的原子性，是分布式锁高可用的基石。

然而无论Redis锁多么强大，它只Neng保证同一时间只有一个线程Neng执行业务代码。它管不了数据库层面的事务提交时机。这就是为什么我们说分布式锁只是第一道防线，而不是全部。

四、 纵深防御：构建无懈可击的数据一致性方案

既然找到了病根——锁释放早于事务提交，那么药方也就呼之欲出了。我们不Neng只依赖一把锁，需要构建从应用层到数据库层的多重防线。

防线一：调整时序，手动控制事务

Zui直接的思路，就是打破Spring AOP的默认行为。既然声明式事务 `@Transactional` 是在方法结束时提交，那我们就放弃它，改用编程式事务管理，即 `TransactionTemplate`。

通过 `TransactionTemplate`，我们Ke以精确控制事务的边界，确保事务提交的动作发生在锁释放之前。

public void decreaseSafe {
    String lockKey = "LOCK:ASSET:" + id;
    redisLock.lock;
    try {
        // 通过 TransactionTemplate 显式控制事务范围
        transactionTemplate.execute(status -> {
            // 1. 查询
            Account account = accountDao.selectById;
            // 2. 计算
            long newBalance = account.getBalance - delta;
            if  {
                status.setRollbackOnly;
                throw new BusinessException;
            }
            // 3. geng新
            account.setBalance;
            accountDao.updateById;
            return null;
        });
        // 🚩 关键点：事务在这里Yi经 Commit 了然后再走下面的 finally 释放锁
        // 此时数据库中的新值Yi经对其他事务可见，锁的释放才真正安全。
    } finally {
        redisLock.unlock;
    }
}

这个改动虽然不大，但却是颠覆性的。它将“事务提交”这一动作强行塞进了“锁持有”的时间窗口内。这样，当线程B拿到锁时它kan到的一定是线程AYi经提交过的Zui新数据。

防线二：拒绝内存计算，将逻辑下沉至数据库

即使我们调整了事务时序，依然存在风险。比如Redis锁因为网络抖动意外失效，或者发生了Full GC导致应用暂停，锁过期了。这时候，Ru果有请求进来依然会基于旧数据覆盖新数据。

所以永远不要在Java代码里计算完余额再执行 `SET balance = #{newValue}`。这种“读-改-写”的模式在并发场景下是脆弱的。

我们应该利用数据库自身的原子性Neng力。将计算逻辑下沉到SQL语句中：

-- 即使两个线程同时进来数据库行锁也会让它们串行执行，且基于Zui新值扣减
UPDATE t_account 
SET balance = balance - #{delta} 
WHERE id = #{id} AND balance>= #{delta}

这条SQL语句的精妙之处在于，它利用了数据库的行锁和原子性。它不需要先查出来而是直接在数据库层面完成减法。geng重要的是我们加上了 `AND balance>= #{delta}` 这个条件。这不仅仅是一个判断，geng是一道CAS 兜底约束。

防线三：CAS 兜底与乐观锁

Ru果业务逻辑复杂，无法简单地用一条SQL表达，那么我们Ke以引入乐观锁机制。在表中增加一个 `version` 字段。

UPDATE t_account 
SET balance = #{newBalance}, version = version + 1 
WHERE id = #{id} AND version = #{oldVersion}

执行geng新后必须检查返回值。Ru果行数为0，说明在读取和geng新之间，Yi经有其他线程修改了数据。此时应用层应该抛出异常或进行重试，而不是默默地覆盖数据。

五、 ：在混乱中寻找秩序

分布式系统开发，本质上就是为数据建立一丝秩序。

这次“数据错乱”的排查经历让我深刻意识到：没有任何一种技术银弹Ke以解决所有问题。 依赖框架的便利性往往会让我们忽略底层的运行机制。真正的专家，不仅要会用工具，geng要理解工具背后的代价和局限。

从Redisson的Lua脚本原子性，到Spring AOP的事务代理，再到数据库层面的行锁与CAS约束，每一层dou有其独特的职责。只有将它们有机地结合起来构建起“纵深防御”的体系，我们才Neng在凌晨三点的报警

记住锁只是守门员，而真正决定比赛胜负的，是你对业务逻辑和数据流转的深刻理解。下次当你写下 `redisLock.lock` 时不妨多问自己一句：我的锁，真的锁住了我想保护的东西吗？

---