【Java多线程进阶】JUC常见类以及CAS机制

1. Callable的用法

之前已经接触过了Runnable接口，即我们可以使用实现Runnable接口的方式创建一个线程，而Callable也是一个interface，我们也可以用Callable来创建一个线程。

• Callable是一个带有泛型的interface
• 实现Callable接口必须重写call方法
• call方法带有返回值，且返回值类型就是泛型类型
• 可以借助FutureTask类接收返回值，更方便的帮助程序员完成计算任务并获取结果

下面我们来举一个案例，要求分别使用实现Runnable接口和Callable接口完成计算1+2+3+…1000并在主线程中打印结果的任务，体会区别。

1.1 使用Runnable接口

public class ThreadDemo01 {private static int result = 0;public static void main(String[] args) throws InterruptedException {Thread t = new Thread(new Runnable() {@Overridepublic void run() {for (int i = 1; i <= 1000; i++) {result += i;}}});// 启动线程t.start();t.join();// 打印结果System.out.println("result: " + result); // 500500}
}

上述代码实现Runnable接口来启动一个线程，这段代码可以实现累加1-1000的任务，但是不够优雅！因为需要额外借助一个成员变量result来保存结果，当业务量繁多时，如果有多个线程完成各自的计算任务，那么就需要更多的成员变量保存结果，因此现在想想带有返回值的线程也许是有必要的！下面我们来看看如何使用Callable接口完成

1.2 使用Callable接口

public class ThreadDemo02 {public static void main(String[] args) throws ExecutionException, InterruptedException {Callable<Integer> callable = new Callable<Integer>() {@Overridepublic Integer call() throws Exception {int result = 0;for (int i = 1; i <= 1000; i++) {result += i;}return result;}};// 创建FutureTask实例FutureTask<Integer> futureTask = new FutureTask<>(callable);// 创建线程并启动Thread t = new Thread(futureTask);t.start();// 阻塞并获取返回结果int result = futureTask.get();System.out.println("result: " + result); // 500500}
}

上述代码中我们使用了实现Callable的方式完成任务，值得一提的是，Callable实现类对象不能直接作为Thread构造方法的参数，我们需要借助一个中间人即 FutureTask 类，该类实现了Runnable接口，因此可以直接作为Thread构造方法的参数。

注：futureTask.get()方法带有阻塞功能，直到子线程完成返回结果才会继续运行

1.3 如何理解FutureTask和Callable

理解Callable：1、Callable与Runnable是相对的，都是描述一个任务，Callable描述带有返回值的任务，Runnable描述不带返回值的任务。2、Callable往往需要搭配FutureTask一起使用，FutureTask用于保存Callable的返回结果，因为Callable中的任务往往在另一个线程执行，具体什么时候执行并不确定
理解FutureTask：FutureTask顾名思义就是未来任务，即Callable中的任务是不确定何时执行完毕的，我们可以形象描述为去杨国福吃麻辣烫时等待叫号，但是什么时候叫号是不确定的，通常点餐完毕后服务员会给一个取号凭证，我们可以凭借这个取号凭证查看自己的麻辣烫有没有做好。

1.4 相关面试题

1. 介绍下Callable是什么？

2. 信号量Semaphore

相信大学期间修过操作系统课的小伙伴对semaphore这个单词并不陌生，这不就是OS的信号量机制可以实现PV操作的么？而JVM对OS提供的semaphore又进行了封装形成了Java标准库中的Semaphore类
semaphore：信号量，用来表示可用资源的数目，本质上是一个计数器。

我们可以拿停车场的展示牌进行举例，当前留有空闲车位100个时，展示牌上就会显示100，表示可用资源的数目，当有汽车开进停车位时，相当于申请了一个可用资源，此时展示牌数目就会-1（称为信号量的P操作），当有汽车驶出停车位，相当于释放了一个可用资源，此时展示牌数目+1（称为信号量V操作）

Semaphore的信号量PV操作都是原子性的，可以直接在多线程环境中使用。

锁其实本质上就是特殊的信号量，加锁可以看作时信号量为0，解锁可以看作信号量为1，所以也有说法称"锁"其实是一个二元信号量，那么既然"锁机制"能够实现线程安全，信号量也可以用来保证线程安全！

2.1 Semaphore代码案例

Semaphore相关API：

1. acquire：相当于P操作，申请一个可用资源
2. release：相当于V操作，释放一个可用资源

代码举例：

1. 创建Semaphore实例并初始化为4，表示有4个可用资源
2. 创建20个线程，每个线程都尝试申请资源，sleep1秒后释放资源，观察程序运行状况

public class SemaphoreExample {public static void main(String[] args) {// 初始化信号量为4Semaphore semaphore = new Semaphore(4);// 创建20个线程for (int i = 0; i < 20; i++) {int id = i;Thread t = new Thread(() -> {try {semaphore.acquire(); // 申请资源System.out.println("线程" + id + "申请到了资源");Thread.sleep(1000); // 睡眠1ssemaphore.release(); // 释放资源System.out.println("线程" + id + "释放资源");} catch (InterruptedException e) {throw new RuntimeException(e);}});// 启动线程t.start();}}
}

执行结果：

其中可以发现当前四个线程申请资源后，此时第五个线程尝试申请资源后，信号量变为-1就会阻塞等待，直到其他线程释放资源后才可以继续申请！

3. CountDownLatch的使用

CountDownLatch：可以等待N个任务全部完成。类似于N个人进行跑步比赛，直到最后一个人跃过终点才会宣布比赛结束，公布最后成绩。

3.1 CountDownLatch相关API

CountDownLatch提供API：

1. new CountDownLatch(int n)：构造方法，初始化n表示有n个任务需要完成
2. countDown()：任务执行完毕后调用，内部计数器进行自减
3. await()：阻塞等待所有任务全部完成后继续执行，相当于等待内部计数器为0

3.2 CountDownLatch代码案例

CountDownLatch代码案例：

1. 创建10个线程，并初始化CountDownLatch为10
2. 每个线程随机休眠1-5秒，模拟比赛结束
3. 主线程中使用await阻塞等待全部执行完毕

public class CountDownLatchExample {public static void main(String[] args) throws InterruptedException {Random random = new Random();// 初始化CountDownLatch为10CountDownLatch latch = new CountDownLatch(10);// 创建10个线程for (int i = 0; i < 10; i++) {int curId = i;Thread t = new Thread(() -> {System.out.println("线程" + curId + "开始执行...");try {Thread.sleep(random.nextInt(6) * 1000);System.out.println("线程" + curId + "结束执行...");latch.countDown(); // 计数器自减} catch (InterruptedException e) {throw new RuntimeException(e);}});// 启动线程t.start();}// 阻塞等待全部执行完毕latch.await();System.out.println("全部任务执行完毕！");}
}

执行结果：

此时我们可以看到调用countDownLatch.await()方法时只有当所有的线程都执行完毕，即调用10次countDown方法后（即内部计数器为0）时才会停止阻塞！

4. ReentrantLock类

ReentrantLock：位于java.util.concurrent包下，被称为可重入互斥锁，和synchronized定位类似，都是用来实现互斥效果的可重入锁，保证线程安全。

4.1 ReentrantLock的用法

ReentrantLock相关API：

1. lock()：尝试加锁，如果加锁失败就阻塞等待
2. tryLock(超时时间)：尝试加锁，获取不到就阻塞等待一定时间，超时则放弃加锁
3. unlock()：解锁

注意：由于ReentrantLock需要手动释放锁，因此常常把unlock方法放在finally块中

ReentrantLock lock = new ReentrantLock();
--------------  相关代码  --------------
lock.lock();
try {// do something...
} finally {lock.unlock();
}

4.2 ReentrantLock与synchronized的区别（经典面试题）

1. synchronized是一个关键字，是JVM内部实现的（大概率使用C++语言实现），而ReentrantLock是一个标准库中提供的类，是在JVM外部实现的（基于Java实现）
2. ReentrantLock使用lock和unlock一对方法进行手动加锁、解锁，相较于synchronized更加灵活，但是也容易遗漏释放锁的步骤。
3. synchronized是非公平锁，而ReentrantLock默认是非公平锁，但是可以变成公平锁，只需要在构造方法中传入参数为true即可。
4. ReentrantLock比synchronized具有更加精准的唤醒机制，synchronized使用Object类的wait/notify进行唤醒，随机唤醒一个等待线程，而ReentrantLock借助类Condition实现等待唤醒，可以精准控制唤醒某一个指定线程。

5. CAS机制

5.1 CAS的基本概念

CAS：全程为compare and swap字面意思就是比较并且交换，一个CAS涉及以下操作：

我们假设内存中的原数据为V，旧的预期值为A，需要修改的新值为B

1. 比较A与V是否相等（比较）
2. 如果比较相等则将B写入内存替换V（交换）
3. 返回操作是否成功。

CAS伪代码：

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

注意：CAS是一个硬件指令，其操作是原子性的，这个伪代码只是辅助理解CAS的工作流程

对CAS原子性的理解：CAS可以看做是乐观锁的一种实现方式，当多个线程同时对某个资源进行CAS操作时，只要一个线程操作成功返回true，其余线程全部返回false，但是不会阻塞。

5.2 CAS的常见应用

5.2.1 实现原子类

标准库中提供了java.util.concurrent.atomic包，里面的类都是基于CAS的方式实现的，最典型的就是AtomicInteger类，其中的getAndIncrement方法相当于i++操作

AtomicInteger atomicInteger = new AtomicInteger(0);
// 相当于i++操作
atomicInteger.getAndIncrement();

下面是AtomicInteger类基于CAS方式的伪代码实现：

class AtomicInteger {private int value;public int getAndIncrement() {int oldValue = value;while (CAS(value, oldValue, oldvalue + 1) != true) {oldValue = value;}return oldValue;}
}

5.2.2 实现自旋锁

基于CAS也可以实现更加灵活的锁，获取到更多的控制权
下面是基于CAS的自旋锁伪代码实现：

class SpinLock {private Thread owner;public void lock() {while (!CAS(owner, null, Thread.currentThread())) {}}public void unlock() {this.owner = null;}
}

5.3 CAS的ABA问题

5.3.1 ABA问题概述

什么是ABA问题：假设现在有两个线程共用一个共享变量num，初始值为A，此时线程t1，期望使用CAS机制将num值修改为Z，线程t1的CAS判定流程如下：

• 如果此时num == A，那么就将内存中的num值修改为Z
• 如果此时num != A，那么就不进行修改，重新判定

但是此时中间穿插了线程t2执行将num值修改为了B，但是又重新修改为了A，所以尽管t1线程比较的预期结果是一致的，但是很可能已经是别人的形状了！

ABA导致的问题

ABA问题有可能会导致严重的后果，比如说我去银行ATM机取钱，考虑采用的时CAS机制，目前我的账户余额为1500，我按下确定按钮想要取出500元钱，但是ATM机卡住了，因此我又按下一次确定按钮，此时正常情况如下：
正常情况：

此时结果是符合预期的！扣款线程t1进行扣款操作，此时余额变为1000元，扣款线程t2判断当前余额已经不为1500了，说明已经扣款成功！于是不进行后续扣款操作！但是如果中间出现其他线程汇款操作，就会出现ABA问题，导致严重后果！
极端情况：

此时扣款线程t1完成扣款操作后，余额变为1000，但是中间穿插了汇款线程t3，刚好往账户中存入金额500，此时扣款线程t3判断余额仍然为1500，因此又进行了多余的一次扣款操作！！！这是相当不合理的

5.3.2 ABA问题解决思路

为了解决ABA带来的问题，我们可以考虑使用 版本号 的思想解决：

• CAS读取数据的时候，同时也要读取版本号
• 如果当前版本号与读取版本号一致，修改数据同时将版本号+1
• 如果当前版本号高于读取版本号，则说明数据已经被修改，当前操作非法

6. 线程安全的集合类

Java提供的集合类大部分都是线程不安全的

Vector，Stack，HashTable是线程安全的（但是官方不推荐使用）

6.1 多线程环境使用ArrayList

1. 自己加锁（使用synchronized或者ReentrantLock实现）
2. 使用Collections.synchronizedList，这是标准库提供的基于synchronized实现的线程安全的类，本质上是在关键方法上加了synchronized修饰
3. 使用CopyOnWriteArrayList，这是一个借助写时拷贝机制实现的容器，常用于配置文件等不经常修改，占用内存较小等场景

写时拷贝机制的核心就是可以对原容器进行并发的读，涉及写操作则先对原容器进行拷贝，然后向新容器中添加元素，最后修改引用，实现了读写分离！

6.2 多线程环境使用队列

1. 自己加锁实现（synchronized或者ReentrantLock实现）
2. 使用标准库提供的BlockingQueue接口及其实现类

6.3 多线程环境使用哈希表

1. 使用HashTable

   只是在关键方法上加上synchronized进行修饰

2. ConcurrentHashMap（常考面试题）

   相比于Hashtable做出了一系列优化（以JDK1.8为例）

   • 优化方式一：读操作没有加锁，只有写操作才会加锁，加锁的方式仍然使用synchronized，但是并不是锁整个对象，而是锁"桶"（使用链表的头结点作为锁对象），大大降低了锁冲突的概率
   • 优化方式二：对于一些变量例如哈希表元素个数size，使用CAS机制避免重量级锁出现
   • 优化方式三：优化了扩容方式，采用"化整为零"，"蚂蚁搬家"的方式，扩容期间新老数组同时存在，一次搬运只搬运少量元素，因此新增操作只需要在新数组中插入即可，查询操作需要在新老数组同时查询，删除操作也需要新老数组同时删除