当前位置：首页 > news >正文

并发编程中的乐观锁与悲观锁

news 2025/9/17 17:22:21

一、核心思想：不同的并发哲学

乐观锁和悲观锁是处理数据竞争（多个线程可能同时修改同一数据）的两种不同策略。它们的区别源于对“冲突发生概率”的不同假设。

特性	悲观锁	乐观锁
哲学	假设冲突很可能发生	假设冲突不太可能发生
机制	先取锁，再操作	先操作，更新前再检查冲突
实现	synchronized, ReentrantLock, FOR UPDATE	CAS、版本号、原子变量
线程状态	其他线程会被阻塞（挂起）	其他线程不被阻塞，可继续执行，但可能需要重试
开销	大（加锁、解锁、上下文切换）	小（无锁操作，但冲突时重试有开销）
适用场景	写操作多，冲突频繁的场景	读操作多，冲突稀少的场景

悲观锁假定冲突非常可能发生。因此，它在访问共享数据之前，会先独占性地锁定资源，阻止其他任何线程访问，直到它完成操作并释放锁。

优点：简单粗暴，能保证最高的数据安全性和一致性。
缺点：性能开销大。加锁和释放锁的操作本身消耗资源，更重要的是，线程的挂起和唤醒是非常昂贵的操作，会导致上下文切换。如果一个线程持有锁的时间很长，其他所有线程都会被阻塞，严重影响系统吞吐量。

写多读少的场景，即冲突发生的概率确实很高。在这种情况下，乐观锁会频繁失败重试，反而可能比悲观锁的直接阻塞性能更差。

乐观锁假定冲突不太可能发生。因此，它不会在访问数据时立即加锁，而是先直接操作数据。但在更新数据的那一刻，它会检查在此期间是否有其他线程修改过这个数据。如果没有，就更新成功；如果有，就更新失败，并进行相应的处理（通常是重试或报错）。

读取与记录：线程A读取数据，并记录下数据的版本号（Version）或某种校验值（如CAS中的旧值）。
操作数据：线程A在本地进行计算修改（这一步不加锁，所以其他线程可能已经修改了数据）。
写前验证：线程A准备将更新写回时，会检查当前的版本号是否和它最初读取的版本号一致。
- 如果一致：说明没有其他线程修改过数据，于是执行更新操作，并通常会增加版本号。
- 如果不一致：说明数据已被其他线程修改，本次更新失败。
失败处理：更新失败后，常见的策略是重试（重新读取最新数据和版本号，然后再次执行整个计算和更新流程）。

CAS指令：CPU级别的原子操作（Compare-And-Swap）。它是乐观锁技术的底层基石。
- 操作：CompareAndSet(oldValue, newValue)。只有在当前值等于 oldValue 时，才会将其设置为 newValue。
原子类：Java中的 AtomicInteger、AtomicLong、AtomicReference 等就是基于CAS实现的。
版本号机制：数据库和乐观锁框架（如Hibernate）中常用。在数据表中增加一个 version 字段。

优点：性能高。在没有冲突的情况下，它完全避免了加锁、解锁、线程阻塞和上下文切换的开销，吞吐量极高。
缺点：
- ABA问题：一个值原来是A，被另一个线程改为B，后又改回A。使用CAS的线程会误以为它没变过。通常通过附加版本号或时间戳来解决。
- 循环时间长开销大：如果冲突频繁，重试操作会持续进行，可能CPU开销很大。
  *** 只能保证一个共享变量的原子操作**。对多个共享变量操作时，CAS无法保证原子性，可能需要用锁。