Java 多线程进阶：锁策略、CAS 与 JUC 组件详解

• 锁消除：编译器优化措施，编译器会对加锁的代码进行判断（但这种判断是非常保守的，只有 100% 确定当前是单线程），如果当前逻辑不需要加锁，编译器就会自动去除 synchronized。
• 锁的粒度：加锁和解锁之间，包含的代码执行的逻辑/时间越多，则锁的粒度就越粗，反之越细。

锁粗化：一个代码对细粒度的代码反复加锁解锁，就会将这个步骤优化为更粗粒度的加锁解锁。

三、CAS

3.1 CAS 概念

CAS: 全称 Compare and swap，字面意思：'比较并交换'，一个 CAS 涉及到以下操作：

我们假设内存中的原数据 V，旧的预期值 A，需要修改的新值 B。比较 A 与 V 是否相等。（比较）如果比较相等，将 B 写入 V。（交换）返回操作是否成功。

伪代码表示如下：

boolean CAS(address, expectValue, swapValue) {
    if (&address == expectedValue) {
        &address = swapValue;
        return true;
    }
    return false;
}

3.2 CAS 应用场景

3.2.1 实现原子类

原子类：特指 java.util.concurrent.atomic 包下的类，这些类中的操作都是原子的。

例如执行下面这段代码：结果就一直是 100000。

import java.util.concurrent.atomic.AtomicInteger;

public class Demo {
    private static AtomicInteger count = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count.incrementAndGet();
            }
        });
        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count.incrementAndGet();
            }
        });
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
        System.out.println(count.get());
    }
}

原子类线程安全的原理：

假设两个线程同时调用 getAndIncrement：两个线程都读取 value 的值到 oldValue 中。(oldValue 是一个局部变量，在栈上，每个线程有自己的栈) 线程 1 先执行 CAS 操作。由于 oldValue 和 value 的值相同，直接进行对 value 赋值。 线程 2 再执行 CAS 操作，第一次 CAS 的时候发现 oldValue 和 value 不相等，不能进行赋值。因此需要进入循环。在循环里重新读取 value 的值赋给 oldValue。 线程 2 接下来第二次执行 CAS，此时 oldValue 和 value 相同，于是直接执行赋值操作。

线程 1 和 线程 2 返回各自的 oldValue 的值即可。

3.2.2 实现自旋锁

基于 CAS 实现更灵活的自旋锁，获取到更多的控制权。

主要逻辑如下：

• 通过 CAS 看当前锁是否被某个线程持有。
• 如果这个锁已经被别的线程持有，那么就自旋等待。
• 如果这个锁没有被别的线程持有，那么就把 owner 设为当前尝试加锁的线程。

伪代码描述如下：

public class SpinLock {
    private Thread owner = null;

    public void lock() {
        while (!CAS(this.owner, null, Thread.currentThread())) {
        }
    }

    public void unlock() {
        this.owner = null;
    }
}

3.3 CAS 的 ABA 问题

3.3.1 ABA 问题简介

假设存在两个线程 t1 和 t2。有一个共享变量 num，初始值为 A。 接下来，线程 t1 想使用 CAS 把 num 值改成 Z，那么就需要先读取 num 的值，记录到 oldNum 变量中。 使用 CAS 判定当前 num 的值是否为 A，如果为 A，就修改成 Z。 但是，在 t1 执行这两个操作之间，t2 线程可能把 num 的值从 A 改成了 B，又从 B 改成了 A。 线程 t1 的 CAS 是期望 num 不变就修改。但是 num 的值已经被 t2 给改了。只不过又改成 A 了。这 个时候 t1 究竟是否要更新 num 的值为 Z。就不符合预期出现 Bug。

过程图：

Bug 例子：

假如你去取钱有 1000，取 500，不小心按了两次取款，我们只想扣一次 500，第一次按相当于 T2，第二次按相当于 T1，先执行 T2 读取操作修改为 500，这时又正好有人给你汇款了 500，内存中与寄存器中又相等了，T1 扣款的操作也会执行成功。

造成 ABA 问题的原因就是内存值既有加又有减，所以我们的解决 ABA 的方式如下。

3.3.2 解决方案

给要修改的值，引入版本号。在 CAS 比较数据当前值和旧值的同时，也要比较版本号是否符合预期。 CAS 操作在读取旧值的同时，也要读取版本号。 真正修改的时候：

• 如果当前版本号和读到的版本号相同，则修改数据，并把版本号 + 1。
• 如果当前版本号高于读到的版本号。就操作失败 (认为数据已经被修改过了)。

四、JUC 组件

JUC 组件就是指 java.util.concurrent 这个包下面的类。

4.1 Callable 接口

Callable 接口就和 java.lang 包下的 Runnable 接口的定位差不多，只不过给了我们一个返回值，在 Runnable 接口要重写 run 方法，而在 Callable 接口中要重写 call 方法。

在使用 Callable 接口传入线程时需要借助 JUC 下的另一个类 FutureTask。

使用例子一般如下：

public class Demo {
    public static void main(String[] args) {
        //创建实现了 Callable 接口的方法
        Callable<Integer> callable = new Callable<Integer>() {
            @Override
            public Integer call() throws Exception {
                return null;
            }
        };
        //将实现 Callable 接口的对象作为参数传入 FutureTask，泛型参数要一致
        FutureTask<Integer> futureTask = new FutureTask<>(callable);
        //将 FutureTask 对象作为参数传入 Thread
        Thread thread = new Thread(futureTask);
    }
}

4.2 ReentrantLock 类

ReentrantLock 类可重入互斥锁，和 synchronized 的定位是差不多的。

ReentrantLock 的用法:

• public void lock(): 加锁，如果获取不到锁就死等。
• public boolean trylock(超时时间): 加锁，如果获取不到锁，等待一定的时间之后就放弃加锁。
• public void unlock(): 解锁。 使用这个类加锁需要我们手动解锁，为避免解锁执行不到的情况，我们一般将 unlock 放在 finally 代码块中。

ReentrantLock locker = new ReentrantLock();
try {
    locker.lock();
} finally {
    locker.unlock();
}

ReentrantLock 与 synchronized 的区别：

• ReentrantLock 是类，是 Java 代码实现的，synchronized 是关键字由 JVM 使用 c++ 代码实现的。
• ReentrantLock 是需要 lock() 方法加锁，unlock() 方法解锁。synchronized 是通过进出代码块加锁解锁。
• ReentrantLock 还提供了 tryLock() 方法可以设置超时时间，不会一直阻塞，加锁成功返回 true，调用者可以根据返回值自己操作。
• ReentrantLock 搭配的通知机制是 Condition 类，可以更精确控制唤醒某个指定的线程，相比 wait / notify 功能更强大。

ReentrantLock 还提供了公平锁的实现，默认是非公平锁，但是构造方法传参 true 实现公平锁。

4.3 Semaphore 类

信号量,：用来表示'可用资源的个数'。本质上就是一个计数器，能够协调多个线程之间的资源调配。 最主要的就是申请资源（P 操作，调用 acquire 方法）释放资源（V 操作，调用 release 方法）

可以把信号量想象成是停车场的展示牌：当前有车位 100 个。表示有 100 个可用资源。当有车开进去的时候，就相当于申请一个可用资源，可用车位就 -1 (这个称为信号量的 P 操作) 当有车开出来的时候，就相当于释放一个可用资源，可用车位就 +1 (这个称为信号量的 V 操作) 如果计数器的值已经为 0 了，还尝试申请资源，就会阻塞等待，直到有其他线程释放资源.

4.4 CountDownLatch 类

CountDownLatch 类的作用：同时等待 N 个任务执行结束。（就像跑步比赛，10 个选手依次就位，哨声响才同时出发；所有选手都通过终点，才能公布成绩。）

使用多线程的时候，经常会把一个大任务拆分为多个子任务，使用 CountDownLatch 衡量子任务完成，让整个任务完成。

• 构造 CountDownLatch 实例，参数传入任务个数，初始化 10 表示有 10 个任务需要完成。
• 每个任务执行完毕，都调用 countDown() 方法。在 CountDownLatch 内部的计数器同时自减。

主线程中使用 await() 方法; 阻塞等待所有任务执行完毕后 wait 结束。相当于计数器为 0 了。