导语：并发控制的核心问题不是“哪种锁更先进”，而是“冲突概率、失败代价与系统吞吐之间如何平衡”。乐观锁与悲观锁代表了两种截然不同的假设：前者假设冲突很少，后者假设冲突随时发生。理解这两种假设背后的成本结构，才能在高并发场景下做出合理取舍。

一、两种锁，两种世界观

乐观锁与悲观锁并不是具体的数据库特性，而是两类并发控制策略的统称。

悲观锁的假设是：并发冲突大概率会发生。因此在读取数据时就加锁，保证从读到改的整个过程中，其他事务无法介入。典型实现包括数据库的 SELECT ... FOR UPDATE、行锁、表锁，以及分布式环境下的 Redis 分布式锁、ZooKeeper 临时节点等。

悲观锁的代价是明确的：持锁期间其他请求被阻塞，锁的粒度越大、持有时间越长，系统的并发能力下降越明显。在极端情况下，还可能因锁等待形成连锁阻塞，甚至引发死锁。

乐观锁的假设则相反：冲突是小概率事件。因此读取时不加锁，只在提交更新时校验数据是否被他人修改过。最常见的实现是版本号机制（version 字段）或 CAS（Compare-And-Swap）思想——更新时带上读取时的版本号，若版本不匹配则更新失败，由业务层决定重试、报错还是放弃。

乐观锁把冲突检测推迟到了写入时刻，用“失败重试”替代了“阻塞等待”。它不占用锁资源，读操作完全不受影响，因此在读多写少的场景下吞吐优势明显。但它的代价同样存在：冲突发生时需要重试，重试意味着额外的计算和请求开销；冲突越频繁，重试成本越高，甚至可能出现大量请求反复失败、有效吞吐反而下降的情况。

二、取舍的核心变量

选择哪种策略，本质上是在回答三个问题。

第一，冲突概率有多高。 这是最直接的判断依据。如果同一行数据在短时间内会被大量请求同时修改——比如秒杀库存扣减、热门账户余额变动——乐观锁的重试率会急剧上升，此时悲观锁或排队机制反而更稳定。反之，如果数据分散、单条记录被并发修改的概率很低，乐观锁几乎不会产生额外成本。

第二，冲突失败的代价有多大。 乐观锁失败后，业务层需要决定如何处理。如果重试是廉价且幂等的，乐观锁的失败成本很低；如果一次失败意味着用户要重新填写表单、重新下单，或者重试会带来副作用，那么把冲突挡在写入之前（悲观锁）可能更合适。

第三，系统的读写比例与响应要求。 乐观锁不阻塞读，适合读多写少、对读延迟敏感的场景；悲观锁会阻塞并发访问，但在写冲突密集时能提供更确定的执行顺序。需要注意的是，这里的“确定”是有代价的——阻塞时间、锁等待超时、死锁检测都会成为新的运维负担。

三、常见误区

误区一：乐观锁一定比悲观锁性能好。 性能取决于冲突率。在低冲突场景下，乐观锁确实开销更小；但在高冲突场景下，大量失败重试会消耗 CPU 和连接资源，实际吞吐可能低于悲观锁，脱离冲突率谈性能没有意义。

误区二：悲观锁就是“重”，乐观锁就是“轻”。 悲观锁的粒度可以很细，行级锁在冲突集中时效率并不低；乐观锁的重试逻辑如果设计不当，同样会拖垮系统。关键不在标签，而在锁的粒度、持有时间和失败处理策略。

误区三：两者只能二选一。 实际系统中，两种策略常常混合使用。例如对核心库存采用悲观锁或队列串行化保证强一致，对非核心的统计字段采用乐观锁减少阻塞。选择的最小单位是“具体的业务操作”，而不是“整个系统”。

四、趋势判断

随着系统规模扩大和分布式架构普及，并发控制的讨论正在从“选哪种锁”转向“如何降低冲突本身”。

一方面，冲突消解前移成为常见思路：通过分片、拆分热点账户、异步化、消息队列串行化等手段，把高冲突场景转化为低冲突场景，从而让乐观锁重新变得可行。另一方面，无锁数据结构与 CAS 原语在语言和中间件层面被广泛使用，乐观思想以更底层的形式渗透进系统设计。

但需要明确的是，乐观锁与悲观锁都不会消失。它们对应的是两种真实的工程约束：前者优化吞吐与读性能，后者优化确定性与冲突隔离。高并发下的数据一致性，从来不是选一个“正确答案”，而是根据冲突分布、失败成本和一致性要求，做出可解释、可验证的取舍。

结论

乐观锁与悲观锁的取舍逻辑可以归纳为一句话：低冲突、重试廉价、读多写少，倾向乐观锁；高冲突、失败代价高、需要确定性顺序，倾向悲观锁。 更重要的是，在选型之前先问一句——这个冲突是否可以通过架构手段消除？很多时候，最好的并发控制，是让冲突根本不发生。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。