悲观锁与乐观锁详解：从Java并发到数据库实战

在 Java 面试的并发编程环节悲观锁和乐观锁几乎是必考题。面试官通常不会满足于你背出“悲观锁默认冲突乐观锁默认不冲突”这两句话而是会继续追问在项目里扣减库存用的是什么锁为什么数据库行锁比 synchronized 更适合如果乐观锁频繁重试怎么办这些问题看起来是考锁的实现实际上是在考你对共享资源竞争、临界区、数据库事务和分布式环境这几个层次的理解是否连贯。这篇文章围绕“悲观锁和乐观锁怎么实现、区别是什么”这条主线先讲清楚两种锁的思想来源再分别落到 Java 和数据库的典型写法上最后用面试场景题、Spring 工程中的常见坑和排查链路收尾。读完以后你不仅能在面试时回答得更完整也能在自己的项目里做出更合理的锁选型。1. 先建立坐标系悲观锁和乐观锁解决的是同一个问题1.1 共享资源竞争与临界区多个线程同时访问同一个共享资源时如果其中至少有一个线程在写就可能出现数据不一致。这个共享资源可以是内存中的变量、数据库表中的一行记录、Redis 中的 Key也可能是文件里的某个字段。无论资源形态如何竞争的本质都是“先读后写”这个复合操作被多个执行流交叉执行了。这个“先读后写”的区间就是临界区。锁的作用不是阻止并发而是让并发线程在进入临界区时按规则排队从而保证临界区内的操作要么整体执行要么整体不执行。理解这一点很关键synchronized、ReentrantLock、数据库行锁、版本号机制、CAS本质上都是对临界区访问策略的不同实现。所谓悲观锁和乐观锁其实是两种不同的并发控制策略。它们的目标一致但对“冲突是否真的会发生”这个前提判断不同因此实现路径也不同。1.2 悲观锁默认会冲突先保护再操作悲观锁的出发点是我假定这个共享数据在操作期间一定会被其他线程修改所以必须先拿到锁把资源保护起来再开始读改写操作。在持锁期间其他线程只能阻塞等待直到锁释放。从这个思想出发你会看到悲观锁通常表现为数据库的SELECT ... FOR UPDATEJava 里的synchronized、ReentrantLock以及分布式环境里的 Redis 分布式锁。它们都有一个共同的形态在操作之前先“占坑”。悲观锁的优点是强一致性缺点是并发性能受锁竞争影响较大。锁持有时间越长等待线程越多系统吞吐量越低。1.3 乐观锁默认不会冲突先操作再校验乐观锁的出发点是我假定这个共享数据在操作期间大概率不会被其他线程修改所以不提前加锁直接执行读改写。但在提交修改的那一刻我要校验一下“在我读取之后有没有别人改过数据”。如果发现数据已经变了就重新读取、重新计算、重新尝试如果没变就提交成功。这个思路听起来有点“赌”的意味但在读多写少的场景下非常高效因为它省去了加锁、阻塞、唤醒这一整套重量级操作。乐观锁最常见的两种实现形式是版本号和 CAS。版本号方式的典型写法是在数据表中加一个version字段更新时用WHERE version ?作为条件成功后让version version 1。CASCompare And Swap则是在 CPU 指令层面完成“比较并交换”Java 中的AtomicInteger等原子类就是基于 CAS 实现的。2. 悲观锁在 Java 中的落地synchronized 与 ReentrantLock2.1 synchronized 的用法与底层机制java里最基础的悲观锁是synchronized。它的使用方式有三种修饰实例方法、修饰静态方法、修饰代码块。这里最容易出错的是锁对象的区别。public class AccountService { private int balance 100; // 实例方法锁的是当前 AccountService 实例 public synchronized void deduct(int amount) { if (balance amount) { balance - amount; } } }上面这段代码中两个线程必须持有同一个AccountService实例synchronized才能互斥。如果每次请求都new一个 Service 对象锁就失去了意义。静态方法锁的是Class对象同一个类的所有实例共享同一把锁public class StockService { // 静态方法锁的是 StockService.class public static synchronized void deductStock(int stockId, int count) { // 扣减库存逻辑 } }代码块则可以精确控制临界区范围避免把不需要保护的操作也放进锁里public void deductWithBlock(int amount) { // 锁粒度更小只保护共享变量的修改 synchronized (this) { if (balance amount) { balance - amount; } } }在 JVM 的实现中synchronized经历过偏向锁、轻量级锁、重量级锁的升级过程。这个升级机制是 JVM 的优化手段不是语言规范的一部分不同 JDK 版本的实现细节可能不同。面试时理解“锁升级”的思想比死记具体阈值更有价值因为这解释了为什么synchronized在低竞争时轻快、高竞争时变重。ReentrantLock的“可重入”意思是同一个线程可以重复获取同一把锁。synchronized同样可重入所以这一点不是ReentrantLock的专利。它真正的优势在下面会展开。2.2 ReentrantLock 比 synchronized 多出来的能力ReentrantLock是java.util.concurrent.locks包下的显式锁需要手动加锁和释放锁。基础用法如下import java.util.concurrent.locks.ReentrantLock; public class OrderService { private final ReentrantLock lock new ReentrantLock(); private int stock 100; public void deduct(int count) { lock.lock(); try { if (stock count) { stock - count; } } finally { lock.unlock(); } } }finally块中的unlock()是必须写的否则一旦业务代码抛出异常锁可能永远不会释放其他线程会永久阻塞。这一点是使用ReentrantLock时最常见的坑。相比synchronizedReentrantLock多出的能力包括可中断lockInterruptibly()允许等待锁的线程被中断避免死等。可超时tryLock(timeout, TimeUnit)在指定时间内获取不到锁就返回false。公平锁构造时传入true让等待时间最长的线程先获得锁。多个条件队列通过newCondition()创建多个等待条件比wait/notify更灵活。下面是一个带超时控制的示例import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.ReentrantLock; public class TimeoutLockDemo { private final ReentrantLock lock new ReentrantLock(); public boolean tryDeduct(int count) { boolean locked false; try { locked lock.tryLock(3, TimeUnit.SECONDS); if (!locked) { System.out.println(获取锁超时放弃本次操作); return false; } // 执行扣减逻辑 } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } finally { if (locked) { lock.unlock(); } } return true; } }这种写法在实际工程里比无条件lock()更稳健。因为在高并发下一个线程卡在锁上等待太久会产生线程阻塞堆积甚至拖垮整个应用。2.3 锁选型不是越复杂越好ReentrantLock功能虽多但日常开发中大部分场景用synchronized就够了。synchronized语法简单不会忘记释放锁JVM 还能自动优化。只有在确实需要超时、可中断、公平排队或多个条件变量时才值得引入ReentrantLock。我也见过有团队把所有方法都改成ReentrantLock理由是“它更强大”结果代码里到处是 try-finally稍不注意就漏掉 unlock。锁的选型应该遵循“最小必要”原则能用简单方案解决就不用复杂方案。这个原则同样适用于后面的乐观锁选型。3. 乐观锁在 Java 中的落地CAS、Atomic 与版本号3.1 先理解 CAS比较并交换CAS 是乐观锁思想的底层原语全称是 Compare And Swap。它接收三个参数内存地址 V、期望值 A、新值 B。只有当 V 当前的值等于 A 时才把 V 更新为 B否则不做任何操作。整个过程是原子的由 CPU 指令保证。Java 中Unsafe类提供了 CAS 能力但我们日常开发不会直接使用Unsafe而是使用基于 CAS 的原子类其中AtomicInteger最典型import java.util.concurrent.atomic.AtomicInteger; public class AtomicCounter { private final AtomicInteger count new AtomicInteger(0); public void increment() { // getAndIncrement 内部就是 CAS 自旋 count.getAndIncrement(); } public int get() { return count.get(); } }CAS 的实现逻辑可以用伪代码理解public class CasSimulation { // current 是期望值next 是新值实际执行是原子的 public boolean compareAndSet(int expected, int next) { // 如果当前值等于 expected就更新为 next // 否则返回 false表示发现并发修改 return true; } }CAS 的优点是避免了线程上下文切换在低竞争场景下性能远好于悲观锁。缺点是 CPU 开销可能较高因为它在循环中反复尝试如果冲突严重自旋会消耗大量 CPU 资源。3.2 Atomic 系列类与 LongAdderAtomicInteger、AtomicLong、AtomicReference是常用的原子类。它们的内部都存在一个循环先读取当前值再计算新值最后通过 CAS 尝试更新。如果更新失败说明有其他线程抢先修改于是重新读取、重新计算。在高并发写非常多的场景下AtomicLong会因为所有线程都自旋争抢同一个变量而产生性能瓶颈。JDK 8 之后提供了LongAdder它把热点分散到多个 Cell 上最终汇总时再相加。这给选型提供了一个参考如果只是统计计数LongAdder更适合高并发写入如果更看重强一致的返回值AtomicLong更直观。import java.util.concurrent.atomic.LongAdder; public class RequestCounter { private final LongAdder count new LongAdder(); public void hit() { count.increment(); } public long total() { return count.sum(); } }3.3 版本号方式的乐观锁CAS 适合内存中的变量但在数据库场景里我们用的是版本号方式。假设订单表有库存字段stock同时加一个version字段更新语句写成这样UPDATE stock SET stock stock - #{count}, version version 1 WHERE id #{id} AND version #{expectVersion};执行时如果当前行的version等于应用层之前读到的expectVersion这次更新会成功同时version自增。如果其他事务已经改过这行version已经变了那么WHERE条件不成立受影响行数为 0。应用层必须判断这个受影响行数int rows stockMapper.deductStock(stockId, count, expectVersion); if (rows 0) { // 说明数据已被其他事务修改需要重试或返回失败 throw new BusinessException(库存更新失败请重试); }这里的重试逻辑需要结合业务决定。可以循环重试几次也可以直接让用户重新提交。如果无限重试在高并发下会浪费数据库资源也没有业务意义。3.4 ABA 问题CAS 有一个经典缺陷叫 ABA 问题。简单说线程 1 读取到值 A线程 2 把值从 A 改成 B又改回 A。此时线程 1 再做 CAS 时发现值还是 A就认为数据没有被修改于是更新成功。但中间其实发生过一次完整的修改。解决 ABA 问题的常用办法是引入版本号或时间戳。Java 中AtomicStampedReference就提供了这样的能力不仅比较引用值还比较邮票标记。import java.util.concurrent.atomic.AtomicStampedReference; public class AbaDemo { private final AtomicStampedReferenceInteger ref new AtomicStampedReference(100, 0); public void update() { int[] stampHolder new int[1]; Integer current ref.get(stampHolder); int currentStamp stampHolder[0]; boolean success ref.compareAndSet(current, 200, currentStamp, currentStamp 1); System.out.println(更新结果: success); } }在实际业务里ABA 是否真的有害要看业务语义。如果共享数据的“值相同”就代表“状态相同”ABA 通常不会造成问题如果中间过程本身就代表业务状态变更就必须引入版本标记。4. 悲观锁和乐观锁的区别与选型4.1 一张表看懂二者的核心差异对比项悲观锁乐观锁核心假设并发冲突大概率发生并发冲突是少数情况典型实现synchronized、ReentrantLock、数据库 FOR UPDATE版本号、CAS、Atomic 类锁粒度需要持有锁阻塞其他线程不阻塞其他线程提交时校验竞争成本阻塞、唤醒、上下文切换自旋重试消耗 CPU一致性强弱强一致冲突时串行最终一致需要重试补偿适用场景写多读少、冲突严重读多写少、冲突较少数据库实现SELECT ... FOR UPDATEUPDATE ... WHERE version ?死锁风险存在需要控制加锁顺序较低但要注意重试风暴悲观锁在并发冲突严重的场景下反而更稳定因为它让线程排队执行避免了乐观锁反复重试带来的 CPU 浪费。乐观锁在冲突少的场景下性能优秀但冲突频繁时会出现大量更新失败和重试。4.2 性能不是唯一指标读多写少与写多读少选型不能只看“乐观锁性能好”这个结论要看冲突概率和业务容忍度。读多写少的场景比如用户资料查询、商品详情展示并发修改同一个数据的概率很低适合乐观锁。此时加悲观锁会白白增加阻塞成本。写多读少的场景比如库存扣减、积分扣减、账户余额变动同一份数据被高频修改乐观锁的 CAS 会频繁失败大量线程都在自旋重试数据库压力也会被成倍放大。这种情况反而应该使用悲观锁让修改操作串行执行。还有一个容易被忽略的点乐观锁要求所有更新方都遵守“先读版本号再更新”的规则。如果系统里有一段代码直接UPDATE stock SET stock stock - 1 WHERE id ?没有带version条件那么乐观锁的保护就形同虚设。这一点在团队协作和接口对接时特别重要。4.3 分布式环境下的锁不能照搬单机实现单机环境下synchronized和ReentrantLock都是 JVM 进程内的锁只能锁住当前进程里的线程。一旦应用部署了多个副本同一个用户请求被负载均衡到不同节点进程内锁就互相不可见了。这时需要引入分布式锁。常见的方案有基于数据库用唯一索引或SELECT ... FOR UPDATE实现但性能有限。基于 Redis使用SET NX EX实现需要处理锁过期和释放时的原子性问题。基于 ZooKeeper利用临时顺序节点实现可靠性较高部署成本也更高。分布式锁并不只是把单机锁换一个实现它还会引入锁超时、锁续期、客户端宕机后锁自动释放、可重入性等一系列问题。在面试中当你说“分布式环境用 Redis 分布式锁”之后面试官通常会追问“锁过期了业务还没执行完怎么办”所以不要把这一层想得太简单。这里不展开分布式锁的具体实现重点是理解悲观锁思想可以跨进程落地为分布式锁乐观锁思想同样可以落地为数据库版本号或 Redis 中的 Lua 脚本比较更新。锁思想是通用的具体载体取决于运行环境。5. 面试中常见的场景题和 Spring 工程里容易踩的坑5.1 秒杀减库存为什么单纯数据库行锁不够面试中特别高频的一道场景题是“秒杀减库存怎么设计”。很多人上来就说“用 synchronized”这在单机演示中可以在真实秒杀场景中是不够的。先看最原始的版本UPDATE stock SET stock stock - 1 WHERE id 1 AND stock 0;这条 SQL 本身就是原子操作。数据库在更新时会锁住这一行两个并发事务不会同时修改成功。所以“减库存”这个动作本身用数据库自带的行锁就能保证正确。问题在于如果库存只有 10 件却有 10000 个请求同时进来大量请求都会阻塞在行锁上导致数据库连接被占满整个服务不可用。这也是为什么真实秒杀系统通常要做前置拦截用 Redis 做库存预扣减或者在应用层先控制入口流量只有少数请求能到达数据库。单纯靠数据库行锁正确性有保证但扩展性不够。如果在这个场景里讲乐观锁就可以这样说UPDATE stock SET stock stock - 1, version version 1 WHERE id 1 AND version 1;用版本号的好处是库存只剩 0 件时更新条件自然不成立不需要额外判断stock 0。但代价是并发量大时很多人会更新失败需要重试或直接提示“已售罄”。5.2 Spring 事务与锁的先后顺序锁失效的一个高频原因这是 Spring 工程里非常容易踩的坑。很多人把锁写在事务方法内部导致事务还没有提交锁就先释放了。看下面的伪代码Transactional public void deductStock(Long stockId, int count) { Stock stock stockMapper.selectById(stockId); if (stock.getStock() count) { throw new BusinessException(库存不足); } stockMapper.updateStock(stockId, count); }如果这个方法的调用方再包一层synchronized或都基于同一把ReentrantLock看起来是先加锁再执行方法但问题出在事务边界上方法执行完锁释放但 Spring 的事务提交可能发生在方法返回之后。另一个线程拿到锁后读到的是尚未提交的旧数据于是出现重复扣减。常见解决办法是把锁的范围扩大到事务提交之后。可以拆成两个方法先提交事务再释放锁或者在事务方法外层包一层非事务方法锁放在外层public void deductWithLock(Long stockId, int count) { lock.lock(); try { // 这里调用的事务方法执行完事务可能还没提交 deductInTransaction(stockId, count); } finally { lock.unlock(); } }这种写法也不是绝对安全因为deductInTransaction返回时事务是否已经提交取决于事务管理器配置和数据库驱动行为。要彻底解决需要理解 Spring 事务的提交时机并把“释放锁”放到事务真正提交之后。一个更稳妥的做法是使用TransactionSynchronizationManager注册事务同步回调在afterCommit中释放锁。TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() { Override public void afterCommit() { lock.unlock(); } });这个细节很容易在面试中展开也是实际项目中锁失效的典型原因。5.3 自旋等待与超时控制乐观锁在冲突时会重试但重试不能没有边界。设计重试时至少要考虑三个参数最大重试次数、每次重试的间隔、超过次数后的处理策略。简单示例如下public boolean deductWithRetry(Long stockId, int count, int maxRetry) { for (int i 0; i maxRetry; i) { Stock stock stockMapper.selectById(stockId); int rows stockMapper.deductByVersion(stockId, count, stock.getVersion()); if (rows 0) { return true; } // 短暂休眠降低对数据库的冲击 Thread.sleep(50); } return false; }如果重试次数和间隔设置得不好乐观锁在冲突严重时会把数据库的查询压力放大数倍。这也是为什么我不建议在秒杀这类高冲突场景下盲目使用乐观锁。5.4 Spring 框架里乐观锁和悲观锁的应用位置java生态中Spring 对锁的支持体现在不同层次Transactional管理事务边界不提供锁语义但悲观锁的SELECT ... FOR UPDATE需要依赖事务。MyBatis 或 MyBatis-Plus 提供了Version注解来简化乐观锁实现底层就是在 SQL 里拼版本号条件。Spring AOP 可以统一管理自定义锁注解常用于分布式锁的切面封装。MyBatis-Plus 的乐观锁插件用法大致如下public class Stock { private Long id; private Integer stock; Version private Integer version; }Update(UPDATE stock SET stock stock - #{count}, version version 1 WHERE id #{id} AND version #{version}) int deductByVersion(Param(id) Long id, Param(count) Integer count, Param(version) Integer version);使用Version注解时要注意每次 update 之前都必须先查询出version否则更新条件缺少期望值乐观锁就无法工作。很多人只加注解但不改变更新 SQL 的写法最终发现锁没有生效。关于 Spring AI 和大模型相关场景这里顺带提一句AI Agent 在执行多任务协作时也会有共享状态竞争比如任务结果写入、幂等控制、上下文版本管理这些场景同样可以用版本号或原子更新来避免重复提交。锁的思路不限于传统 Web 应用。6. 排查链路与最佳实践6.1 从阻塞、报错和数据异常倒推锁问题如果你在项目里发现数据错乱或接口阻塞可以按下面的清单排查。问题现象可能原因检查方式处理建议接口偶尔超时线程全部卡住悲观锁锁范围过大或持锁时间过长查看线程堆栈检查等待锁的线程缩小临界区减少持锁时间ReentrantLock第二次调用时永远阻塞上一次调用忘记unlock()检查代码里是否没有 finally 释放统一使用 try-finally 或 try-with-resources乐观锁更新一直返回 0 行version条件不匹配冲突频繁打印更新 SQL 和传入的版本号增加重试策略或改用悲观锁SELECT ... FOR UPDATE没有生效查询没有在事务中执行检查方法是否有Transactional先把事务边界补齐多个实例部署后锁失效使用了 JVM 进程内锁确认应用是否多副本部署改用分布式锁库存出现负数减库存 SQL 缺少stock 0条件查看历史 SQL 和更新条件添加数量校验和WHERE stock count事务提交前锁已释放锁在事务方法内部释放早于提交查看锁和事务的代码顺序把锁提升到事务外层或注册 afterCommit 回调排查时建议先看线程堆栈。jstack可以输出 Java 进程的线程状态能直接看到哪些线程在等待锁、卡在哪个方法上jstack pid thread_dump.txt在 dump 文件里搜索locked和waiting to lock关键字可以快速定位阻塞点。6.2 项目落地时的几个硬性建议基于实际项目经验下面这些建议可以避免大部分锁相关问题第一锁粒度要尽量小。不要把整个方法都放进锁里只保护真正需要保护的共享变量。锁范围越大并发度越低。第二持锁时间要尽量短。不要持锁执行远程调用、IO 操作、大数据量查询。如果必须做建议把耗时不稳定的操作移到锁外面或者调整锁策略。第三乐观锁必须保证所有更新路径都带版本条件。如果有一条 SQL 绕过版本号直接更新乐观锁机制就被破坏了。可以在代码审查时重点检查这一点。第四重试必须有上限。乐观锁失败后不能无限循环要设置最大重试次数、退避间隔、失败后的降级策略。第五synchronized和ReentrantLock只能保证单进程内的正确性。上线前确认应用是否多实例部署如果是就要考虑分布式锁。第六数据库的悲观锁依赖事务。SELECT ... FOR UPDATE必须在事务中执行事务提交或回滚时锁才会释放。没有事务的查询锁会在语句结束后立刻释放这往往不是期望行为。6.3 面试回答时的一个可用提纲面试时被问到悲观锁和乐观锁可以按这个顺序回答第一层讲思想。悲观锁默认冲突先加锁再操作乐观锁默认不冲突提交时通过版本号或 CAS 校验。第二层讲实现。悲观锁对应 Java 的synchronized、ReentrantLock、数据库的SELECT ... FOR UPDATE乐观锁对应版本号、AtomicInteger等原子类。第三层讲区别。从冲突假设、适用场景、性能表现、实现复杂度几个维度做对比。第四层讲场景。读多写少选乐观锁写多读少选悲观锁单机用 JVM 锁多实例用分布式锁库存扣减等强一致场景要特别小心事务和锁的顺序。第五层讲自己踩过的坑。比如 Spring 事务提交前锁已经释放导致数据错乱或者乐观锁重试没有上限导致数据库压力过大。这一步能体现真实项目经验比单纯背八股文有说服力。面试官追问时最常出现的两个延伸点是“CAS 的 ABA 问题怎么解决”和“分布式锁怎么保证锁过期后业务还能安全执行”。建议把这两个问题也提前准备好和本文内容配合练习会比孤立地背锁的概念有效得多。