乐观锁、悲观锁、分布式锁，几乎是后端面试和项目实践里绕不开的三个概念。如果只看定义，它们似乎并不难理解：
乐观锁：假设并发冲突不严重，更新数据时再校验是否被别人改过；
悲观锁：假设并发冲突一定会发生，操作前先加锁，再执行后续逻辑；
分布式锁：在多服务节点部署的场景下，保证同一时刻只有一个节点能执行某段逻辑。
很多人背到这里，就觉得自己已经掌握了，但真正到了面试追问或者项目落地时，问题往往就开始了：
很多人第一次听到“乐观锁”时，会下意识觉得它是一种“真的加了锁”的机制。其实不是，乐观锁不强调“先锁住”，而强调“更新时确认数据还是不是我看到的那份数据”。
在并发场景下，多个请求可能同时修改同一份数据，如果没有任何控制，就容易出现覆盖更新的问题。
比如，商品库存原本是10：
最常见的做法，是给数据加一个version版本号字段。
比如一条商品记录长这样：
id = 1 stock = 10 version = 3
当某个请求读到这条数据时，它不仅会读到库存，也会读到当前版本号。后续更新时，不是直接根据id去更新，而是带着这个version一起更新：
update product
set stock = stock - 1,
version = version + 1
where id = 1
and version = 3;
这条 SQL 的关键点不在stock - 1，而在：
and version = 3
只有当这条数据的版本号还是我最初读到的 3 时，我这次更新才允许成功。
如果更新成功，说明这期间没人动过这条数据。
如果更新失败，说明别的请求已经先一步改过了，你当前这次操作所基于的数据已经过期。
假设现在有一个“普通商品扣库存”的场景，库存初始值为
stock = 10 version = 5
这时请求A和请求B同时进来。
第一步，请求A和请求B都查询到
stock = 10 version = 5
然后两个请求都准备执行更新。
第二步，请求 A 先执行：
update product
set stock = 9,
version = 6
where id = 1
and version = 5;
执行成功，数据库中数据变成：
stock = 9 version = 6
第三步，接着请求 B 再执行：
update product
set stock = 9,
version = 6
where id = 1
and version = 5;
这时候就会失败，因为数据库中的version已经不是5，而是6了。
这就是乐观锁的本质：不是抢着先锁住资源，而是通过版本一致性校验，拒绝基于旧数据的更新。
如果说乐观锁的思路是“先假设冲突不常发生”，
那悲观锁正好相反：它先假设冲突一定会发生，所以干脆在操作前先把资源锁住。
悲观锁的重点不是“更新失败后怎么补救”，而是在真正修改数据之前，就先阻止别人同时改。
悲观锁解决的依然是并发场景下对同一份数据的竞争更新问题。
但它和乐观锁的处理方式完全不同。
乐观锁是：
悲观锁是：
所以从结果上看，悲观锁更像是在并发场景下，把对关键数据的修改强行串行化。
可以用一个账户余额扣减的例子来解释悲观锁。
假设一个账户当前余额是100元，现在同时来了两个扣款请求：
如果没有做好并发控制，就可能出现问题：
结果两个请求都通过了校验，总共扣了110元，账户上没有那么多钱，这样账户就出问题了。
在后端开发里，最常见的悲观锁实现，就是数据库的行锁。
select * from account
where id = 1
for update;
这条SQL的核心是最后的：
for update
它表示：在当前事务提交之前，把这条记录锁住。后续如果其他事务也想对这条记录加锁或修改这条记录，就必须等待当前事务释放锁。
还是刚刚提到的余额扣减例子，如果应用悲观锁的话，会变成下面这样：
第一步，请求A先开启事务并加锁：
select balance from account
where id = 1
for update;
数据库把这条账户记录锁住。
第二步，请求B也来了，它如果也想对同一条账户记录执行for update，就会被阻塞，必须等待请求A提交事务。
第三步，请求A在事务里完成校验和更新，
第四步，请求A释放锁后，请求B才能获得锁，才能进行查询操作，这时它再查余额，读到的已经是最新值20，然后会发现20 < 30，余额不足，从而扣款失败。
这样一来，系统就不会出现“两个请求都基于旧余额通过校验”的问题。
讲到这里，很多人会自然地把分布式锁和乐观锁、悲观锁并列理解，觉得它们只是“不同类型的锁”。
但严格来说，它们并不完全在同一个维度上。
因为前两者主要解决的是：并发更新同一份数据时，如何保证结果正确。而分布式锁更关注的是：在多个服务实例同时运行的情况下，某个动作到底该由谁来执行。
分布式锁很多时候锁的不是“某条数据库记录”，而是：
在单机应用里，如果你想让一段代码同一时刻只能被一个线程执行，往往可以直接用synchronized和ReentrantLock。
这类本地锁的前提是，所有竞争者都在同一个进程、同一台机器里。
但后端服务一旦真正上线，往往不会只部署一个实例。这时候问题就来了，比如你写了一个定时任务，代码里加了synchronized，你以为这样就能保证“同一时刻只执行一次”。但实际上：
在工程里，分布式锁的实现方式不止一种，但最常见的是Redis分布式锁。
最基础的做法通常类似这样：
SET lock_key unique_value NX PX 30000
分布式锁最关键的不是“加锁成功”本身，而是“锁的持有、过期、释放”都要设计清楚，因为它不像本地锁那样天然可靠，分布式锁涉及网络、超时、节点故障，所以边界问题会多很多。
用“定时任务只允许一个实例执行”这个经典例子来讲解：
假设系统部署了服务A和服务B两个实例，现在有一个定时任务，每天凌晨扫描超时订单并自动取消。
如果没有分布式锁，那么在同一时刻，服务A会触发一次任务，服务B也会触发一次任务。
这样就可能出现：
很多人会说：“那我不是已经写了幂等了吗？”幂等当然很重要，但它解决的是“重复执行后结果尽量不出错”；
而分布式锁解决的是：从源头上减少重复执行，让同一时刻只有一个实例先进去做。他们解决问题的侧重点不一样。
一个典型流程通常是这样：
第一步，服务A和服务B同时触发任务，它们都准备执行“取消超时订单”，然后都去竞争同一把锁，锁名为：
cancel_timeout_order_task_lock
第二步，只有一个实例抢锁成功，假设服务A成功抢到了锁，服务A开始执行业务。
第三步，服务B因为没抢到锁，所以直接退出，或者稍后重试，直到服务A执行完成后释放锁，下一轮任务再重新竞争。
写到这里，其实最重要的已经不是再去背“乐观锁是什么、悲观锁是什么、分布式锁是什么”了。真正决定你能不能把这类问题讲明白的，是你有没有意识到：这三种锁根本不是同一个维度上的技术点。
很多人会把它们并排记忆，然后试图总结成“乐观锁轻一点，悲观锁重一点，分布式锁更高级一点”。
这种记法最容易在面试和项目里出问题，因为它会让你忽略一个关键事实：乐观锁、悲观锁主要解决的是数据竞争，分布式锁主要解决的是执行权竞争。
| 类型 | 核心解决的问题 | 锁/控制的对象 | 常见实现 | 适合场景 | 主要优势 | 主要代价 |
|---|---|---|---|---|---|---|
| 乐观锁 | 并发更新同一份数据时，避免基于旧数据覆盖更新 | 数据版本一致性 | version 版本号、CAS、时间戳 |
读多写少、冲突少的更新场景 | 并发性能好，不容易阻塞 | 冲突多时失败率高，需要重试 |
| 悲观锁 | 并发更新同一份关键数据时，保证强互斥和强一致 | 数据访问权 | 数据库行锁、select ... for update |
写冲突高、强一致要求高的场景 | 逻辑直观，一致性更稳 | 阻塞明显，吞吐下降，可能死锁 |
| 分布式锁 | 多个服务节点同时竞争某个业务动作的执行权 | 某段业务逻辑的执行资格 | Redis、ZooKeeper、数据库锁表/唯一约束辅助 | 定时任务单点执行、全局互斥、避免重复执行 | 能跨节点控制互斥 | 实现边界复杂，要处理超时、误删、故障等问题 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。