孤舟笔记并发篇五乐观锁和悲观锁到底啥区别？面试为什么总爱问这对冤家-平芜编程栈

文章目录

- 先说结论：两种截然不同的"世界观"
- 悲观锁：宁可错杀，不可放过
- 乐观锁：先干了再说，冲突了我重试
- 乐观锁的翻车现场：ABA 问题
- 乐观锁 vs 悲观锁：到底选谁？
- 乐观锁与悲观锁全景
- 回答技巧与点评
- - - 标准回答
    - 加分回答
    - 面试官点评

个人网站

你写代码的时候，有没有纠结过这个问题——多个线程要改同一份数据，到底该不该加锁？加了锁，性能差；不加锁，数据可能被改乱。更头疼的是，面试官总喜欢问"乐观锁和悲观锁的区别"，你背了半天定义，一追问场景就懵了。

今天咱们就把这对"冤家"彻底拆开，看看它们各自在什么场景下能大显身手。

先说结论：两种截然不同的"世界观"

||| 维度 | 说明 |
|||------|------|
||| 悲观锁 | 认为冲突一定会发生，先锁再说 |
||| 乐观锁 | 认为冲突大概率不会发生，先干后验 |
||| 悲观锁实现 | synchronized、ReentrantLock |
||| 乐观锁实现 | CAS、版本号机制（Version） |
||| 悲观锁适用场景 | 写多读少、竞争激烈 |
||| 乐观锁适用场景 | 读多写少、竞争不激烈 |
||| 悲观锁缺点 | 阻塞等待，上下文切换开销大 |
||| 乐观锁缺点 | 冲突时自旋重试，消耗 CPU |

一句话记住：悲观锁像锁门上厕所，乐观锁像超市自助结账——先扫码，冲突了再重试。

悲观锁：宁可错杀，不可放过

想象你去一个只有一个坑位的公共厕所。进去第一件事干啥？锁门。你不会先看看有没有人来，再决定锁不锁——因为你假设随时可能有人来抢。

悲观锁就是这个思路：不管有没有冲突，我先拿到锁再说。没拿到锁的线程？排队等着，等锁释放了再来。

在 Java 里，synchronized和ReentrantLock都是悲观锁的典型实现：

synchronized(lock){// 进入这段代码前，必须拿到锁 👈balance-=100;}

没有悲观锁会怎样？两个线程同时读到余额是 500，各自减 100，写回去都变成 400，凭空少了 100 块。这就是经典的"丢失更新"问题。

悲观锁的好处是简单粗暴、绝对安全。坏处也显而易见——如果 10 个线程只有 1 个要写，其他 9 个都在读，结果 9 个读线程也被堵在外面，这性能也太浪费了。

乐观锁：先干了再说，冲突了我重试

再看超市自助结账。你扫码付款的时候，不会先锁住整个货架——你假设大概率没人跟你抢同一个商品。先操作，提交的时候再检查有没有冲突。

乐观锁就是这个逻辑：先不管锁，直接改数据，提交时验证是否有其他线程改过。如果没有，提交成功；如果有，重试或者报错。

最常见的乐观锁实现方式有两种：

1. CAS（Compare And Swap）

AtomicIntegercount=newAtomicInteger(0);count.incrementAndGet();// 底层就是 CAS 👈// 比较：当前值是不是我读到的值？是→更新；不是→重试

2. 版本号机制（数据库乐观锁常用）

UPDATEaccountSETbalance=balance-100,version=version+1WHEREid=1ANDversion=5;👈-- 版本不对就更新失败

没有乐观锁会怎样？那就只能用悲观锁，即使 100 次操作只有 1 次冲突，也得每次都加锁。就像超市每次结账都要清场，太离谱了。

乐观锁的翻车现场：ABA 问题

乐观锁看起来很美，但它有个经典翻车场景——ABA 问题。

假设线程 A 读到值是 1，准备 CAS 更新。这时候线程 B 把 1 改成 2，又改回 1。线程 A 一比较，值还是 1，CAS 成功了——但这个 1 已经不是原来的 1 了！

生活类比：你把一份文件放在桌上，去接了个电话。回来一看，文件还在原位——但你不知道中间有人拿走过，看了内容，又放回去了。

解决方案？用版本号，或者 Java 提供的AtomicStampedReference，给值加个"邮票"，每次修改邮票 +1：

AtomicStampedReference<Integer>ref=newAtomicStampedReference<>(1,1);// 值1，版本1 👈// CAS 时同时比较值和版本号，杜绝 ABA

乐观锁 vs 悲观锁：到底选谁？

选锁的核心原则就一条：看竞争程度。

写多读少，竞争激烈→ 悲观锁。因为冲突概率高，乐观锁会疯狂重试，CPU 自旋到怀疑人生。
读多写少，竞争不激烈→ 乐观锁。大部分时候没有冲突，加锁纯属浪费性能。

一个常见误区：乐观锁一定比悲观锁快。错！如果冲突特别频繁，乐观锁的重试开销比加锁还大。就像堵车的时候，你非要走小路绕来绕去，结果每条小路都堵，还不如老老实实排大队。

实际项目中，很多框架已经帮你做了选择。比如 MyBatis-Plus 的@Version注解就是乐观锁，而synchronized是悲观锁，根据场景选用就行。

乐观锁与悲观锁全景

锁策略 全景 核心概念 ├── 悲观锁 ── 先锁后用，阻塞等待 │ ├── synchronized（JVM 层面） │ └── ReentrantLock（API 层面） └── 乐观锁 ── 先用后验，冲突重试 ├── CAS（Compare And Swap） ├── 版本号机制（Version） └── AtomicStampedReference（解决 ABA） 选择策略 ├── 写多读少 → 悲观锁 ├── 读多写少 → 乐观锁 └── 竞争激烈 → 悲观锁（避免自旋浪费） 口诀：悲观锁门防冲突，乐观扫码先做主， 写多用悲少用乐，ABA 问题版本补。

回答技巧与点评

标准回答

乐观锁和悲观锁是两种并发控制策略。悲观锁认为冲突一定会发生，操作前先加锁，确保独占访问，典型实现有 synchronized 和 ReentrantLock；乐观锁认为冲突大概率不会发生，先操作再验证，冲突时重试，典型实现有 CAS 和版本号机制。悲观锁适用于写多读少的场景，乐观锁适用于读多写少的场景。

加分回答

设计原则：乐观锁体现了"先假设最好情况"的设计思想，类似"宽容优先"策略；悲观锁体现了"防御优先"策略，两者本质是性能与安全的权衡
ABA 问题与边界：乐观锁的 ABA 问题是经典陷阱，可用AtomicStampedReference或版本号解决。此外，乐观锁在极高并发下会导致大量自旋重试，反而比悲观锁性能更差——乐观锁不是银弹
实际应用：数据库层面，MyBatis-Plus 用@Version实现乐观锁，SELECT ... FOR UPDATE是悲观锁；分布式场景中，Redis 的WATCH/MULTI也是乐观锁思想