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() {
@Override
public 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>() {
@Override
public 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 相关面试题
- 介绍下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：
- acquire：相当于P操作，申请一个可用资源
- release：相当于V操作，释放一个可用资源
代码举例：
- 创建Semaphore实例并初始化为4，表示有4个可用资源
- 创建20个线程，每个线程都尝试申请资源，sleep1秒后释放资源，观察程序运行状况
public class SemaphoreExample {
public static void main(String[] args) {
// 初始化信号量为4
Semaphore 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); // 睡眠1s
semaphore.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：
- new CountDownLatch(int n)：构造方法，初始化n表示有n个任务需要完成
- countDown()：任务执行完毕后调用，内部计数器进行自减
- await()：阻塞等待所有任务全部完成后继续执行，相当于等待内部计数器为0
3.2 CountDownLatch代码案例
CountDownLatch代码案例：
- 创建10个线程，并初始化CountDownLatch为10
- 每个线程随机休眠1-5秒，模拟比赛结束
- 主线程中使用await阻塞等待全部执行完毕
public class CountDownLatchExample {
public static void main(String[] args) throws InterruptedException {
Random random = new Random();
// 初始化CountDownLatch为10
CountDownLatch 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：
- lock()：尝试加锁，如果加锁失败就阻塞等待
- tryLock(超时时间)：尝试加锁，获取不到就阻塞等待一定时间，超时则放弃加锁
- unlock()：解锁
注意：由于ReentrantLock需要手动释放锁，因此常常把unlock方法放在finally块中
ReentrantLock lock = new ReentrantLock();
-------------- 相关代码 --------------
lock.lock();
try {
// do something...
} finally {
lock.unlock();
}
4.2 ReentrantLock与synchronized的区别（经典面试题）
- synchronized是一个关键字，是JVM内部实现的（大概率使用C++语言实现），而ReentrantLock是一个标准库中提供的类，是在JVM外部实现的（基于Java实现）
- ReentrantLock使用lock和unlock一对方法进行手动加锁、解锁，相较于synchronized更加灵活，但是也容易遗漏释放锁的步骤。
- synchronized是非公平锁，而ReentrantLock默认是非公平锁，但是可以变成公平锁，只需要在构造方法中传入参数为true即可。
- ReentrantLock比synchronized具有更加精准的唤醒机制，synchronized使用Object类的wait/notify进行唤醒，随机唤醒一个等待线程，而ReentrantLock借助类Condition实现等待唤醒，可以精准控制唤醒某一个指定线程。
5. CAS机制
5.1 CAS的基本概念
CAS：全程为compare and swap字面意思就是比较并且交换，一个CAS涉及以下操作：
我们假设内存中的原数据为V，旧的预期值为A，需要修改的新值为B
- 比较A与V是否相等（比较）
- 如果比较相等则将B写入内存替换V（交换）
- 返回操作是否成功。
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
- 自己加锁（使用synchronized或者ReentrantLock实现）
- 使用
Collections.synchronizedList，这是标准库提供的基于synchronized实现的线程安全的类，本质上是在关键方法上加了synchronized修饰 - 使用CopyOnWriteArrayList，这是一个借助写时拷贝机制实现的容器，常用于配置文件等不经常修改，占用内存较小等场景
写时拷贝机制的核心就是可以对原容器进行并发的读，涉及写操作则先对原容器进行拷贝，然后向新容器中添加元素，最后修改引用，实现了读写分离！
6.2 多线程环境使用队列
- 自己加锁实现（synchronized或者ReentrantLock实现）
- 使用标准库提供的BlockingQueue接口及其实现类
6.3 多线程环境使用哈希表
-
使用HashTable
只是在关键方法上加上synchronized进行修饰
-
ConcurrentHashMap（常考面试题）
相比于Hashtable做出了一系列优化（以JDK1.8为例）
- 优化方式一：读操作没有加锁，只有写操作才会加锁，加锁的方式仍然使用synchronized，但是并不是锁整个对象，而是锁"桶"（使用链表的头结点作为锁对象），大大降低了锁冲突的概率
- 优化方式二：对于一些变量例如哈希表元素个数size，使用CAS机制避免重量级锁出现
- 优化方式三：优化了扩容方式，采用"化整为零"，"蚂蚁搬家"的方式，扩容期间新老数组同时存在，一次搬运只搬运少量元素，因此新增操作只需要在新数组中插入即可，查询操作需要在新老数组同时查询，删除操作也需要新老数组同时删除
![BulingBuling - 《研究巴菲特》 [ Buffettology ]](https://img-blog.csdnimg.cn/direct/c3cde4b62f26413fba4ebf5f01e4dcbe.png)
![[VulnHub靶机渗透] Fowsniff](https://img-blog.csdnimg.cn/direct/bd6b4ffe81224a4790735433244caeb1.png)
