乐观锁和悲观锁
乐观锁和悲观锁问题，是出现频率比较高的面试题。本文将由浅入深，逐步介绍它们的基本概念、实现方式 (含实例)、适用场景，以及可能遇到的面试官追问，希望能够帮助你打动面试官。
一、基本概念
乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。
- 乐观锁：乐观锁在操作数据时非常乐观，认为别人不会同时修改数据。因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行操作。
- 悲观锁：悲观锁在操作数据时比较悲观，认为别人会同时修改数据。因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。
二、实现方式 (含实例)
在说明实现方式之前，需要明确：乐观锁和悲观锁是两种思想，它们的使用是非常广泛的，不局限于某种编程语言或数据库。
悲观锁的实现方式是加锁，加锁既可以是对代码块加锁（如 Java 的 synchronized 关键字），也可以是对数据加锁（如 MySQL 中的排它锁）。
乐观锁的实现方式主要有两种：CAS 机制和版本号机制，下面详细介绍。
1、CAS（Compare And Swap）
CAS 操作包括了 3 个操作数：
- 需要读写的内存位置 (V)
- 进行比较的预期值 (A)
- 拟写入的新值 (B)
CAS 操作逻辑如下：如果内存位置 V 的值等于预期的 A 值，则将该位置更新为新值 B，否则不进行任何操作。许多 CAS 的操作是自旋的：如果操作不成功，会一直重试，直到操作成功为止。
这里引出一个新的问题，既然 CAS 包含了 Compare 和 Swap 两个操作，它又如何保证原子性呢？答案是：CAS 是由 CPU 支持的原子操作，其原子性是在硬件层面进行保证的。
下面以 Java 中的自增操作 (i++) 为例，看一下悲观锁和 CAS 分别是如何保证线程安全的。我们知道，在 Java 中自增操作不是原子操作，它实际上包含三个独立的操作：（1）读取 i 值；（2）加 1；（3）将新值写回 i
因此，如果并发执行自增操作，可能导致计算结果的不准确。在下面的代码示例中：value1 没有进行任何线程安全方面的保护，value2 使用了乐观锁 (CAS)，value3 使用了悲观锁 (synchronized)。运行程序，使用 1000 个线程同时对 value1、value2 和 value3 进行自增操作，可以发现：value2 和 value3 的值总是等于 1000，而 value1 的值常常小于 1000。
public class Test {
//value1：线程不安全
private static int value1 = 0;
//value2：使用乐观锁
private static AtomicInteger value2 = new AtomicInteger(0);
//value3：使用悲观锁
private static int value3 = 0;
private static synchronized void increaseValue3(){
value3++;
}
public static void main(String[] args) throws Exception {
//开启1000个线程，并执行自增操作
for(int i = 0; i < 1000; ++i){
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
value1++;
value2.getAndIncrement();
increaseValue3();
}
}).start();
}
//打印结果
Thread.sleep(1000);
System.out.println("线程不安全：" + value1);
System.out.println("乐观锁(AtomicInteger)：" + value2);
System.out.println("悲观锁(synchronized)：" + value3);
}
}首先来介绍 AtomicInteger。AtomicInteger 是 java.util.concurrent.atomic 包提供的原子类，利用 CPU 提供的 CAS 操作来保证原子性；除了 AtomicInteger 外，还有 AtomicBoolean、AtomicLong、AtomicReference 等众多原子类。
下面看一下 AtomicInteger 的源码，了解下它的自增操作 getAndIncrement() 是如何实现的（源码以 Java7 为例，Java8 有所不同，但思想类似）。
public class AtomicInteger extends Number implements java.io.Serializable {
//存储整数值，volatile保证可视性
private volatile int value;
//Unsafe用于实现对底层资源的访问
private static final Unsafe unsafe = Unsafe.getUnsafe();
//valueOffset是value在内存中的偏移量
private static final long valueOffset;
//通过Unsafe获得valueOffset
static {
try {
valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
public final int getAndIncrement() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return current;
}
}
}源码分析说明如下：
（1）getAndIncrement() 实现的自增操作是自旋 CAS 操作：在循环中进行 compareAndSet，如果执行成功则退出，否则一直执行。
（2）其中 compareAndSet 是 CAS 操作的核心，它是利用 Unsafe 对象实现的。
（3）Unsafe 又是何许人也呢？Unsafe 是用来帮助 Java 访问操作系统底层资源的类（如可以分配内存、释放内存），通过 Unsafe，Java 具有了底层操作能力，可以提升运行效率；强大的底层资源操作能力也带来了安全隐患 (类的名字 Unsafe 也在提醒我们这一点)，因此正常情况下用户无法使用。AtomicInteger 在这里使用了 Unsafe 提供的 CAS 功能。
（4）valueOffset 可以理解为 value 在内存中的偏移量，对应了 CAS 三个操作数 (V/A/B) 中的 V；偏移量的获得也是通过 Unsafe 实现的。
（5）value 域的 volatile 修饰符：Java 并发编程要保证线程安全，需要保证原子性、可视性和有序性；CAS 操作可以保证原子性，而 volatile 可以保证可视性和一定程度的有序性；在 AtomicInteger 中，volatile 和 CAS 一起保证了线程安全性。关于 volatile 作用原理的说明涉及到 Java 内存模型 (JMM)，这里不详细展开。
说完了 AtomicInteger，再说 synchronized。synchronized 通过对代码块加锁来保证线程安全：在同一时刻，只能有一个线程可以执行代码块中的代码。synchronized 是一个重量级的操作，不仅是因为加锁需要消耗额外的资源，还因为线程状态的切换会涉及操作系统核心态和用户态的转换；不过随着 JVM 对锁进行的一系列优化 (如自旋锁、轻量级锁、锁粗化等)，synchronized 的性能表现已经越来越好。
2、版本号机制
除了 CAS，版本号机制也可以用来实现乐观锁。版本号机制的基本思路是在数据中增加一个字段 version，表示该数据的版本号，每当数据被修改，版本号加 1。当某个线程查询数据时，将该数据的版本号一起查出来；当该线程更新数据时，判断当前版本号与之前读取的版本号是否一致，如果一致才进行操作。
需要注意的是，这里使用了版本号作为判断数据变化的标记，实际上可以根据实际情况选用其他能够标记数据版本的字段，如时间戳等。
下面以 “更新玩家金币数” 为例（数据库为 MySQL，其他数据库同理），看看悲观锁和版本号机制是如何应对并发问题的。
考虑这样一种场景：游戏系统需要更新玩家的金币数，更新后的金币数依赖于当前状态 (如金币数、等级等)，因此更新前需要先查询玩家当前状态。
下面的实现方式，没有进行任何线程安全方面的保护。如果有其他线程在 query 和 update 之间更新了玩家的信息，会导致玩家金币数的不准确。
@Transactional
public void updateCoins(Integer playerId){
//根据player_id查询玩家信息
Player player = query("select coins, level from player where player_id = {0}", playerId);
//根据玩家当前信息及其他信息，计算新的金币数
Long newCoins = ……;
//更新金币数
update("update player set coins = {0} where player_id = {1}", newCoins, playerId);
}为了避免这个问题，悲观锁通过加锁解决这个问题，代码如下所示。在查询玩家信息时，使用 select …… for update 进行查询；该查询语句会为该玩家数据加上排它锁，直到事务提交或回滚时才会释放排它锁；在此期间，如果其他线程试图更新该玩家信息或者执行 select for update，会被阻塞。
@Transactional
public void updateCoins(Integer playerId){
//根据player_id查询玩家信息（加排它锁）
Player player = queryForUpdate("select coins, level from player where player_id = {0} for update", playerId);
//根据玩家当前信息及其他信息，计算新的金币数
Long newCoins = ……;
//更新金币数
update("update player set coins = {0} where player_id = {1}", newCoins, playerId);
}版本号机制则是另一种思路，它为玩家信息增加一个字段：version。在初次查询玩家信息时，同时查询出 version 信息；在执行 update 操作时，校验 version 是否发生了变化，如果 version 变化，则不进行更新。
@Transactional
public void updateCoins(Integer playerId){
//根据player_id查询玩家信息，包含version信息
Player player = query("select coins, level, version from player where player_id = {0}", playerId);
//根据玩家当前信息及其他信息，计算新的金币数
Long newCoins = ……;
//更新金币数，条件中增加对version的校验
update("update player set coins = {0}, version = version + 1 where player_id = {1} and version = {2}", newCoins, playerId, player.version);
}三、优缺点和适用场景
乐观锁和悲观锁并没有优劣之分，它们有各自适合的场景；下面从两个方面进行说明。
1、功能限制
与悲观锁相比，乐观锁适用的场景受到了更多的限制，无论是 CAS 还是版本号机制。
例如，CAS 只能保证单个变量操作的原子性，当涉及到多个变量时，CAS 是无能为力的，而 synchronized 则可以通过对整个代码块加锁来处理。再比如版本号机制，如果 query 的时候是针对表 1，而 update 的时候是针对表 2，也很难通过简单的版本号来实现乐观锁。
2、竞争激烈程度
如果悲观锁和乐观锁都可以使用，那么选择就要考虑竞争的激烈程度：
- 当竞争不激烈 (出现并发冲突的概率小) 时，乐观锁更有优势，因为悲观锁会锁住代码块或数据，其他线程无法同时访问，影响并发，而且加锁和释放锁都需要消耗额外的资源。
- 当竞争激烈 (出现并发冲突的概率大) 时，悲观锁更有优势，因为乐观锁在执行更新时频繁失败，需要不断重试，浪费 CPU 资源。
四、面试官追问：乐观锁加锁吗？
笔者在面试时，曾遇到面试官如此追问。下面是我对这个问题的理解：
（1）乐观锁本身是不加锁的，只是在更新时判断一下数据是否被其他线程更新了；AtomicInteger 便是一个例子。
（2）有时乐观锁可能与加锁操作合作，例如，在前述 updateCoins()的例子中，MySQL 在执行 update 时会加排它锁。但这只是乐观锁与加锁操作合作的例子，不能改变 “乐观锁本身不加锁” 这一事实。
五、面试官追问：CAS 有哪些缺点？
面试到这里，面试官可能已经中意你了。不过面试官准备对你发起最后的进攻：你知道 CAS 这种实现方式有什么缺点吗？
下面是 CAS 一些不那么完美的地方：
1、ABA 问题
假设有两个线程——线程 1 和线程 2，两个线程按照顺序进行以下操作：
(1) 线程 1 读取内存中数据为 A；
(2) 线程 2 将该数据修改为 B；
(3) 线程 2 将该数据修改为 A；
(4) 线程 1 对数据进行 CAS 操作
在第 (4) 步中，由于内存中数据仍然为 A，因此 CAS 操作成功，但实际上该数据已经被线程 2 修改过了。这就是 ABA 问题。
在 AtomicInteger 的例子中，ABA 似乎没有什么危害。但是在某些场景下，ABA 却会带来隐患，例如栈顶问题：一个栈的栈顶经过两次 (或多次) 变化又恢复了原值，但是栈可能已发生了变化。
对于 ABA 问题，比较有效的方案是引入版本号，内存中的值每发生一次变化，版本号都 + 1；在进行 CAS 操作时，不仅比较内存中的值，也会比较版本号，只有当二者都没有变化时，CAS 才能执行成功。Java 中的 AtomicStampedReference 类便是使用版本号来解决 ABA 问题的。
2、高竞争下的开销问题
在并发冲突概率大的高竞争环境下，如果 CAS 一直失败，会一直重试，CPU 开销较大。针对这个问题的一个思路是引入退出机制，如重试次数超过一定阈值后失败退出。当然，更重要的是避免在高竞争环境下使用乐观锁。
3、功能限制
CAS 的功能是比较受限的，例如 CAS 只能保证单个变量（或者说单个内存值）操作的原子性，这意味着：(1)原子性不一定能保证线程安全，例如在 Java 中需要与 volatile 配合来保证线程安全；(2)当涉及到多个变量 (内存值) 时，CAS 也无能为力。
除此之外，CAS 的实现需要硬件层面处理器的支持，在 Java 中普通用户无法直接使用，只能借助 atomic 包下的原子类使用，灵活性受到限制。