乐观锁与悲观锁

乐观锁与悲观锁是处理并发访问共享数据时的两种基本策略,核心区别在于对冲突发生概率的假设不同,以及由此选择的加锁时机不同。它们广泛应用于数据库、缓存和并发编程之中。

概述

当多个线程或事务同时读写同一份数据时,可能产生更新丢失、脏读等问题。为保证数据正确,需要并发控制。悲观锁走保守路线,认为冲突随时会发生,因此在操作数据前就先加锁;乐观锁走乐观路线,认为冲突罕见,先不加锁,直到提交时才检查数据是否被别人改过。

核心特点

• 悲观锁:操作前先获取锁,独占资源,其他事务必须等待。数据库中的行锁、表锁、SELECT FOR UPDATE 都属于悲观锁。
• 乐观锁:不加锁,读取时记录版本信息,更新时校验版本是否变化,未变则提交并递增版本,已变则说明发生冲突,需要重试或放弃。
• 乐观锁常见实现有版本号机制和比较并交换(CAS)。
• 悲观锁保证了独占性但降低并发度且可能死锁;乐观锁并发度高但冲突多时会频繁重试。

应用场景

• 读多写少、冲突概率低的场景适合乐观锁,如商品浏览、内容展示中的偶尔更新。
• 写多、冲突频繁、必须保证强一致的场景适合悲观锁,如账户扣款、库存扣减的关键路径。
• Java 的原子类、数据库的版本字段、Redis 的 WATCH 事务都是常见落地方式。

常见问题

问:乐观锁一定比悲观锁性能好吗?答:不一定。在冲突很少时乐观锁避免了加锁开销,性能更好;但在高冲突场景下会频繁重试,反而浪费资源,此时悲观锁更稳妥。选择取决于实际的读写比例和冲突频率。

问:乐观锁如何解决 ABA 问题?答:仅比较值可能出现值被改回原样导致误判成功的 ABA 问题。通过引入版本号或带标记的原子引用,让每次修改都改变版本,即可识别中间发生过的变化。