探索JAVA并发 - 悲观锁和乐观锁

什么是悲观锁，什么是乐观锁，它们是如何实现的？

定义

悲观锁：对世界充满不信任，认为一定会发生冲突，因此在使用资源前先将其锁住，具有强烈的独占和排他特性。
乐观锁：相信世界是和谐的，认为接下来的操作不会和别人发生冲突，因此不会上锁，直接进行计算，但在更新时还是会判断下这期间是否有人更新过(该有的谨慎还是不能少)，再决定是重新计算还是更新。

悲观锁

悲观锁认为一定会有人和它同时访问目标资源，因此必须先将其锁定，常见的synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

举个简单的例子感受一下:

import java.util.concurrent.atomic.AtomicInteger;

public class Main {

    // java提供的一个可以进行原子操作的类，对它进行加减不会受多线程影响
    // 虽然这里实际上用不到
    private static AtomicInteger count = new AtomicInteger();

    public static void main(String[] args) throws Exception {
        for (int i = 0; i < 5; i++) {
            new Thread(() -> {
                while (true) {
                    System.out.println(Thread.currentThread().getName() + " waiting");
                    visit();
                }

            }).start();
        }
    }

    private static synchronized void visit() {
        System.out.println(Thread.currentThread().getName()
                + " is coming, count = " + count.incrementAndGet());
        try {
            Thread.sleep((long) (Math.random() * 5000));
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        count.decrementAndGet();
    }

}

/* 输出:

Thread-0 waiting
Thread-0 is coming, count = 1
Thread-1 waiting
Thread-2 waiting
Thread-3 waiting
Thread-4 waiting
Thread-0 waiting
Thread-4 is coming, count = 1
Thread-4 waiting
Thread-3 is coming, count = 1
Thread-3 waiting
Thread-2 is coming, count = 1
Thread-2 waiting
Thread-1 is coming, count = 1
Thread-2 is coming, count = 1
Thread-1 waiting
Thread-2 waiting
Thread-3 is coming, count = 1
Thread-3 waiting
Thread-4 is coming, count = 1
Thread-4 waiting
Thread-0 is coming, count = 1
Thread-0 waiting
Thread-4 is coming, count = 1

*/

从输出可以看到，每次有线程访问这个资源(方法)时，count都是1，也就是说只有一个线程在访问它，这个线程在访问前先锁定了资源，导致其他线程只能等待。

乐观锁

乐观锁总是假设会遇到最好的情况，即这个资源除了我没人感兴趣，没人和我抢。虽然理想是美好的，但现实往往是残酷的，所以也不能盲目乐观，还是需要保证并发操作时不会对资源造成错误影响。可以使用版本号机制和CAS算法实现。

版本号机制

常用于数据库的版本控制中，即每个数据版本有个版本号字段，每次数据被修改，版本号就会增加。

当一个操作要更新一个数据时，先读取当前版本号并记录，然后修改数据，在提交更新时检测版本号是否变化，如果没变化就应用更新，变化了就重试更新。

CAS算法

Compare-And-Swap，比较并交换。

这种算法一般接收两个参数：预估值(expectedValue)和更新值(newValue)，返回一个布尔值（是否更新成功）。如下：

1	boolean compareAndSwap(int expectedValue,int newValue);

实现逻辑为，将预估值(expectedValue)和真实值(realValue)比较，如果相同，则把真实值(realValue)修改为更新值(newValue)，返回true，否则返回false。

使用Java代码模拟CAS实现：

public class CASer {

    // 真实值
    private volatile int realValue;

    // 获取当前值
    public int get() {
        return realValue;
    }

    // 自增指定值并获取自增后的值
    public synchronized int addAndGet(int increment) {
        // 不断CAS直到更新成功
        // 经常在源码中看到的是for(;;)这种写法，一种说法是两者编译出来的指令不同
        // for(;;)编译后指令更简单更快
        // 如果不是对性能很敏感随意就好，另外有的编译器可能会在编译时帮你优化成最佳指令
        while (true) {
            int expectedValue = get();
            int newValue = expectedValue + increment;
            if (compareAndSwap(expectedValue, newValue)) {
                return newValue;
            }
        }
    }

    // CAS
    // 如果当前值是expectedValue，则替换成newValue
    private synchronized boolean compareAndSwap(int expectedValue, int newValue) {
        if (expectedValue == realValue) {
            realValue = newValue;
            return true;
        }
        return false;
    }
}

为了模拟CAS，这里用到了synchronized关键字让方法变成同步方法，真这样用CAS也就没必要了，那么Java中是怎么实现CAS的呢？可以在原子类里找到答案。

基于CAS的AtomicInteger

java.util.concurrent.atomic.* 包下提供了一些基本类型的原子变量类，可以在并发场景进行原子的加减操作，它们就是用到了CAS。

从源码开始理解：

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;

    // setup to use Unsafe.compareAndSwapInt for updates
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            // 获取某个字段相对Java对象的“起始地址”的偏移量
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    // 使用volatile保证可见性
    private volatile int value;

    // 增加指定值，并返回增加后的值
    public final int addAndGet(int delta) {
        return unsafe.getAndAddInt(this, valueOffset, delta) + delta;
    }

可以看到，AtomicInteger使用volatile保证真实值的可见性，然后使用Unsafe类提供的CAS操作来更新value的值。

Unsafe类名字看上去不太好听，但它确实不太安全。

Unsafe类是在sun.misc包下，不属于Java标准。但是很多Java的基础类库，包括一些被广泛使用的高性能开发库都是基于Unsafe类开发的，比如Netty、Cassandra、Hadoop、Kafka等。Unsafe类在提升Java运行效率，增强Java语言底层操作能力方面起了很大的作用。

Unsafe类使Java拥有了像C语言的指针一样操作内存空间的能力，同时也带来了指针的问题。过度的使用Unsafe类会使得出错的几率变大，因此Java官方并不建议使用的，官方文档也几乎没有。

public final class Unsafe {

    private static final Unsafe theUnsafe;

    // 单例模式，私有化构造方法
    private Unsafe() {
    }

    public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

    public native int getIntVolatile(Object var1, long var2);

    public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);

从源码中可以看出，Unsafe的CAS是通过一系列本地方法实现的。使用了硬件级别的原子操作，效率很高。

CAS算法缺陷

只能操作一个共享变量

从上面的分析可以看出，CAS只能对单个变量有效，如果有多个资源需要一起使用似乎无法实现。但实际上是有办法的，Java中提供了一个原子引用类，让我们可以以对象为目标进行原子操作，那就是AtomicReference。把多个共享资源放到一个对象中，然后通过AtomicReference包装这个对象即可。类似还有操作数组的AtomicReferenceArray。

过度消耗CPU

由于CAS可能会无法更新值，那么一般是在一个循环中不断尝试知道成功，如果竞争很大，有些线程长时间循环，会导致过度消耗CPU。因此CAS更适合在读比写多的情况下使用，反之慎用。

ABA问题

再看看开始提到CAS时定义的方法：

1	boolean compareAndSwap(int expectedValue,int newValue);

如果真实值等于expectedValue，就能肯定这期间没人操作过资源吗？显然不能，比如另一个线程先把一个数+1，然后又-1。此时虽然值没变，但它已经经历了你不知道的事。

那么ABA会造成什么恶劣影响呢？

答案是一般不会（不会我说个锤子？但我就是要说，至少面试中经常问到），只能说一般我们期望保证在操作过程中没有其它人访问过这个资源，我才会应用我这段时间的更新（乐观锁也是锁啊，当然要保证这段时间只有我在操作啊，虽然我没锁定，但原则问题不能迁就），但是ABA使我们期望落空了，我们还不能察觉。

想举个ABA造成不良影响的例子，硬是想不出来，网上也没找到喜欢的，有没有大佬留言来一个？

ABA解决方案：核心思想就是，用于判断是否更新的值不能变回用过的值，这需要业务逻辑上做一定调整。Java中的解决方案是AtomicStampedReference，一个带版本号的原子引用类，比较时不比较业务中要用的值（这个值可能又回到最初的起点），使用一个版本号，每次修改都将版本号增加，也就是前面提到的版本号机制。

总结

悲观锁：锁定资源 -> 使用 -> 释放资源
乐观锁：获取资源快照 -> 使用 -> 确定资源没改变 -> 更新
悲观锁适用竞争激烈的场景，乐观锁反之
乐观锁可以用版本号机制 + CAS算法实现