【JavaEE -- 多线程进阶 - 面试重点】
多线程进阶
- 1. 常见锁策略
-
- 1.1 乐观锁和悲观锁
- 1.2 轻量级锁和重量级锁
- 1.3 自旋锁和挂起等待锁
- synchronized具有自适应能力
- 1.4 普通互斥锁和读写锁
- 1.5 公平锁和非公平锁
- 1.6 可重入锁和不可重入锁
- 2. Synchronized原理（特点、加锁过程、自适应）
-
- 2.1 Synchronized基本特点
- 2.2 Synchronized加锁过程
- 2.3 锁消除
- 2.4 锁粗化
- 3. CAS（compare and swap）
-
- 3.1 CAS 的ABA问题怎么解决
- 4. Callable接口
- 5. JUC（java.util.concurrent）的常见类
-
- 5.1 ReentrantLock
- 6. 信号量Semaphore
-
- 6.1 使用Semaphore可以保证线程安全，就相当于synchronized加锁
- 7. CountDownLatch
- 8. ConcurrentHashMap
-
- 8.1 ConcurrentHashMap（Java1.8）的改进
1. 常见锁策略
加锁过程中，处理冲突的过程中，涉及到一些不同的处理方式。
1.1 乐观锁和悲观锁
- 乐观锁：在加锁之前，预估当前出现锁冲突的概率不大，因此在进行加锁的时候就不会做太多的工作，加锁的过程中做的事情比较少，加锁的速度比较快，但是更容易引入一些其他的问题，可能会消耗更多的cpu资源。
- 悲观锁：在加锁之前，预估当前锁冲突出现的概率比较大，因此在加锁的时候做更多的工作，做的事情更多，加锁的速度可能更慢，但是整个过程中不容易出现其他问题。
- 乐观锁的实现：引入一个版本号，借助版本号识别出当前的数据访问是否冲突。
- 悲观锁的实现：先加锁（比如借助操作系统提供的mutex），获取到锁再操作数据，获取不到就等待。
1.2 轻量级锁和重量级锁
按加锁开销的大小分：
- 轻量级锁：加锁的开销小，加锁的速度更快，轻量级锁一般就乐观锁。
- 重量级锁：加锁的开销大，加锁的速度更慢，重量级锁一般是悲观锁。
轻量和重量是加锁之后对结果的评价，乐观和悲观是加锁之前，对未发生的事情进行的预估，整体来说，这两种角度描述的是同一个事情。
1.3 自旋锁和挂起等待锁
- 自旋锁：是轻量级锁的一种典型实现，进行加锁的时候，搭配一个while循环，如果加锁成功，自然循环结束。如果加锁不成功，不是阻塞放弃cpu，而是进行下一次循环，再次尝试获取到锁。这个反复快速执行的过程就称为自旋。一旦其他线程释放了锁，就能第一时间拿到锁。同时这样的自旋锁也就是乐观锁。自旋的前提：就是预期冲突的概率不大，其他线程释放了锁，就能第一时间拿到锁。当加锁的线程很多，自旋的意义就不大了，会浪费CPU资源。
- 挂起等待锁：重量级锁的一种典型实现，进行等待挂起等待的时候，就需要内核调度器介入，这一块要完成的操作很多，真正获取到锁花的时间就更多。同时也是一种悲观锁，这个锁可以适用于锁冲突激烈的情况。
synchronized具有自适应能力
- 如果当前锁冲突的激烈程度不大，就处于乐观锁/轻量级锁/自旋锁。
- 如果当前锁冲突的激烈程度很大，就处于悲观锁/重量级锁/挂起等待锁。
1.4 普通互斥锁和读写锁
一个线程对于数据的访问，主要存在两种操作：读数据和写数据。
- 两个线程都只是读一个数据，此时并没有线程安全问题，之间并发的读取即可。
- 两个线程都要写一个数据，有线程安全问题。
- 一个线程读另外一个线程写，有线程安全问题。
- 普通互斥锁：多线程之间，数据的读取时之间不会产生线程安全问题，但是数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁，就会产生极大的性能损耗，所以引出读写锁。
- 读写锁：在执行加锁操作时需要额外表明读写意图，复数读者之间并不互斥，而写者则要求与任何人互斥。读写锁分为两种情况，加 读锁和加 写锁。
- 读锁和读锁之间，不会出现锁冲突（不会阻塞，即不互斥）。
- 写锁和写锁之间，会出现锁冲突（会阻塞，即互斥）。
- 读锁和写锁之间，会出现锁冲突（会阻塞，即互斥）。
一个线程加 读锁的时候，另一个线程只能读，不能写。一个线程加 写锁的时候，另一个线程，不能读也不能写。
1.5 公平锁和非公平锁
假如三个线程A，B，C，A先尝试获取锁，获取成功，然后B再尝试获取锁，获取失败，阻塞等待；然后C也尝试获取锁，C也获取失败，阻塞等待。
- 公平锁：遵守 “先来后到”，当A释放锁，B先于C拿到锁。
- 非公平锁：B和C都有可能获取到锁。
Java中synchronized是非公平锁。
1.6 可重入锁和不可重入锁
- 可重入锁：一个线程针对一把锁，连续两次加锁，不会死锁。synchronized是可重入锁，实现方式：在加锁中记录锁持有的线程身份，以及一个计数器（记录加锁次数），如果发现加锁的线程就是持有锁的线程，则直接计数自增。
- 不可重入锁：一个线程针对一把锁，连续两次加锁，会死锁。系统自带的锁是不可重入的锁。
2. Synchronized原理（特点、加锁过程、自适应）
2.1 Synchronized基本特点
- 开始是乐观锁，如果锁冲突频繁，转换为悲观锁（自适应）
- 开始是轻量级锁实现，如果锁被持有的时间较长，就转换为重量级锁（自适应）
- 实现轻量级锁的时候大概率用到自旋锁策略（自适应）
- 是一种不公平锁
- 是一种可重入锁
- 不是读写锁
2.2 Synchronized加锁过程
当线程执行到Synchronized的时候，如果这个对象当前处于为加锁的状态，就会经历以下过程：
- 偏向锁阶段：假设没有线程竞争。 核心思想就是懒汉模式，能不加锁就不加锁，能晚加锁就晚加锁。所谓的偏向锁，并非真的加锁了，而只是做了一个非常轻量的标记。非必要不加锁，在遇到竞争的情况下，偏向锁没有提高效率，但如果实在没有竞争的情况下，偏向锁就大幅度提高了效率。
- 轻量级锁阶段：假设有竞争，但是不多。此处就是通过自旋锁的方式来实现的；优势：另外的线程把锁释放了，就会第一时间拿到锁。劣势：比较消耗cpu，即对于自旋锁来说，如果同一个锁竞争者很多，大量线程都在自旋，整体cpu的消耗就很大。此同时，synchronized内部会统计当前这个锁对象上，有多少个线程在参与竞争，当参与竞争的线程多了就会进一步升级到重量级锁。
- 重量级锁阶段：锁竞争进一步激烈，此处的重量级锁就是指用到内核提供的mutex，此时拿不到锁的线程就不会继续自旋了，而是进入阻塞等待，让出cpu，当当前线程释放锁的时候，就由系统随机唤醒一个来获取锁。
2.3 锁消除
锁消除也是synchronized中内置的优化策略。编译器优化的一种方式，编译器编译代码的时候，如果发现这个代码，不需要加锁，就会自动把锁给干掉。针对一眼看上去就不涉及安全问题的代码，能够把锁消除掉，对于其他的很多模棱两可的，都不会消除。
2.4 锁粗化
锁粗化，会把多个细粒度的锁，合并成一个粗粒度的锁。粒度指的是synchronized {}里大括号里面包含代码越少，就认为锁的粒度越细，包含的代码越多，就认为锁的粒度越粗。
通常情况下，是更偏于让锁的粒度细一些，更有利于多个线程并发执行的，但有时候也希望粒度粗点好.
如A给B交代任务，打电话，交代任务1，挂电话。打电话，交代任务2，挂电话。打电话，交代任务3，挂电话。粗化成，打电话，交代任务1，2，3.挂电话。把这三个合并一个粗粒度的锁，粗化提高了效率。
小结：synchronized的优化操作
- 锁升级：偏向锁 -> 轻量级锁 -> 重量级锁
- 锁消除：自动干掉不必要的锁
- 锁粗化：把多个细粒度的锁合并成一个粗粒度的锁，减少锁竞争。
3. CAS（compare and swap）
CAS是一个特殊的cpu的指令，完成的工作就是 比较 和 交换。是单个cpu指令，本身是原子的，同时完成 读取内存，比较是否相等，修改内存。
CAS的伪代码：
比较address内存地址中的值，是否和expected寄存器中的值相同，如果相同，就把swap寄存器的值和address内存的值，进行交换，返回true。如果不相同，直接返回false。
- CAS本身是cpu指令，操作系统对指令进行了封装，jvm又对操作系统提供的api又封装了一层，有的cpu可能会不支持cas，而Java的标准库，对于CAS又进行了进一步的封装，提供了一些工具类，里面最主要的一个工具，原子类。
- 之前的线程安全都是靠加锁，加锁-》阻塞-》性能降低。基于CAS指令，不涉及加锁，不会阻塞，合理使用也保证线程安全，即无锁编程。
public class ThreadDemo34 {
// AtomicInteger: Java标准库中，对cas又进一步的封装，提供了一些工具类，即原子类
// 使用原生的int 会出现线程安全问题 ，不使用加锁，使用AtomicInteger替换int也能保证线程安全
// private static int count = 0;
private static AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
//getAndIncrement 对变量的修改，是一个cas指令，即这个指令天然就是原子的
//count++;
count.getAndIncrement();
// ++count;
//count.incrementAndGet();
// count += n;
//count.getAndAdd(n);
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
//count++;
count.getAndIncrement();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
}
3.1 CAS 的ABA问题怎么解决
假如去ATM取钱，里面有1000，要取500，取钱的时候ATM卡了，按了一下没反应（t1线程），又按了一下（t2线程），此时此时产生了两个线程，去尝试扣款操作，此处 假如按CAS的方式扣款，这样是没问题的。当又来个t3线程给账户存了500，此时t1线程就不知道当前的1000是始终没变还是变了又变回来了。
解决方案：
- 约定数据变化是单向的（只能增加或者只能减少），不能是双向的（即又增加又能减少）。
- 对于本身就必须双向变化的数据，可以给它引入一个版本号，版本号这个数字是只能增加，不能减少。
4. Callable接口
- 继承Thread（包含了匿名内部类的方式）
- 实现Runnable（包含了匿名内部类的方式）
- 基于lambda
- 基于Callable
- 基于线程池
- Runnable关注的是这个过程，不关注执行结果，Runnable提供的是run方法，返回值类型是void
public class ThreadDemo35 {
private static int sum = 0;
public static void main(String[] args) throws InterruptedException {
// 创建一个新线程，用新的线程实现从1+到1000
// 不用callable
Thread t = new Thread(new Runnable() {
@Override
public void run() {
int result = 0;
for (int i = 0; i <= 1000; i++) {
result += i;
}
sum = result;
}
});
t.start();
t.join();
// 主线程获取到计算结果
// 此处想要获取到结果，就需要弄一个成员变量保持上述结果
System.out.println("sum= " + sum);
}
}
- Callable要关注执行结果，Callable提供的call方法，返回值就是线程执行任务得到的结果
- callable 通常搭配FutureTask来使用，FutureTask用来保存Callable的返回结果，因为callable往往是在另一个线程中执行的，什么时候执行完不确定。
- FutureTask类，作为Thread和callable的粘合剂，使用futureTask.get()获取结果，带有阻塞功能，如果线程还没有执行完，get就会阻塞，等待线程执行完。
当编写多线程代码，希望关注线程中代码的返回值的时候：
相比于runnable来说，不需要引入额外的成员变量，直接借助这个的返回值即可。
import java.util.concurrent.*;
// Callable 接口
public class ThreadDemo36 {
public static void main(String[] args) throws ExecutionException, InterruptedException {
// 期望线程的入口方法里，返回值是啥类型，此处的泛型就是什么类型 这里希望返回值是Integer
Callable<Integer> callable = new Callable<Integer>() {
@Override
public Integer call() throws Exception {
int result = 0;
for (int i = 0; i <= 1000; i++) {
result += i;
}
return result;
}
};
//Thread没有提供构造函数传入callable
// 引入一个FutureTask类，作为Thread和callable的粘合剂 未来的任务，相当于一个凭据
FutureTask<Integer> futureTask = new FutureTask<>(callable);
Thread t = new Thread(futureTask);
t.start();
// 接下来这个代码不需要join，使用futureTask获取到结果
// futureTask.get() 这个操作也具有阻塞功能，如果线程还没有执行完毕，get就会阻塞，等到线程执行完了，
//return的结果就会被get返回回来
System.out.println(futureTask.get());
}
}
5. JUC（java.util.concurrent）的常见类
5.1 ReentrantLock
用法：
- lock() :加锁,如果获取不到锁就死等
- unlock()，解锁
- trylock(超出时间)：加锁，如果获取不到锁，等待一定的时间之后就放弃加锁。
ReentrantLock,可重入锁，和synchronized一样是可重入锁，有了synchronized为什么还需要ReentrantLock：
- ReentrantLock提供了tryLock操作，lock直接进行加锁，如果加锁不成，就要阻塞；tryLock，尝试进行加锁，如果加锁成功，不阻塞，直接返回false，即tryLock提供了更多的可操作空间。
- Reentrant Lock提供了公平锁的实现（通过队列记录加锁线程的先后顺序），ReentrantLock构造方法中填写参数，就可以设置公平锁，而synchronized是非公平锁。
- 搭配的等待通知机制不同的，synchronized，搭配wait / notify，对于Reentrant Lock，搭配Condition类，功能比wait / notify 略强一点。
6. 信号量Semaphore
信号量，用来表示 可用资源的个数，本质上就是一个计数器。
import java.util.concurrent.Semaphore;
// 信号量 Semaphore
public class ThreadDemo37 {
public static void main(String[] args) throws InterruptedException {
Semaphore semaphore = new Semaphore(1);
// 申请1个资源
semaphore.acquire();
System.out.println("P 操作");
semaphore.acquire();
System.out.println("P 操作");
// 释放一个资源
semaphore.release();
System.out.println("V 操作");
}
}
- new一个semaphore对象，有1个可用资源
- semaphore.acquire ：申请一个资源，资源个数 -1（P操作）
- semaphore.release ：释放一个资源，资源个数 +1 （V操作）
- 如果计数器为0，即没有可用资源了，还申请资源，就会阻塞等待，直到有其他线程释放资源。
- Semaphore的PV操作的加减操作都是原子的，可以在多线程下直接使用。
所谓的锁，本质上也是一种特殊的信号量，锁，可以认为计数值为1的信号量，释放状态，就是1，加锁状态，就是0，对于非0即1的信号量，称为二元信号量，信号量是更广义的锁。
6.1 使用Semaphore可以保证线程安全，就相当于synchronized加锁
使用Semaphore，先申请一个资源然后进行下述count++操作，再进行释放操作，这样也可以确保线程安全。
import java.util.concurrent.Semaphore;
// 信号量 Semaphore
// 在操作前先申请一个可用资源 使数字-1 semaphore.acquire(); 后semaphore.release(); 数字+1 释放一个可用资源
// 加锁状态， 就是 0 ，释放状态，就是1 对于非0即1的信号量就称为 二元信号量
public class ThreadDemo38 {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
Semaphore semaphore = new Semaphore(1);
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
try {
semaphore.acquire();
} catch (InterruptedException e) {
e.printStackTrace();
}
count++;
semaphore.release();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
try {
semaphore.acquire();
} catch (InterruptedException e) {
e.printStackTrace();
}
count++;
semaphore.release();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
}
小结
确保线程安全的操作：
- synchronized
- ReentrantLock
- CAS（原子类）
- Semaphore
7. CountDownLatch
CountDownLatch，同时等待N个任务执行结束，比如，多线程执行一个任务，把大的任务拆成几个部分，由每个线程分别执行。
- 构造CountDownLatch实例，初始化10表示10个任务线程需要完成
- 每个任务执行完毕，都调用latch.countDown()，在CountDownLatch 内部的计数器同时自减
- 主线程中使用latch.await()，阻塞等待所有任务结束，相当于计数器为0
** join() ,就只能每个线程执行一个任务，而使用CountDownLatch就可以一个线程执行多个任务**。
public class ThreadDemo39 {
public static void main(String[] args) throws InterruptedException {
// 1.此处构造方法中写10，意思是有10个线程任务
CountDownLatch latch = new CountDownLatch(10);
// 创建出 10个线程负责下载
for (int i = 0; i < 10; i++) {
int id = i;
Thread t = new Thread(() -> {
Random random = new Random();
int time = (random.nextInt(5) + 1) * 1000;
System.out.println("线程 "+id+"开始下载");
try {
Thread.sleep(time);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("线程结束 " + id + "结束下载");
// 2.告知 CountDownLacth 执行结束了
latch.countDown();
});
t.start();
}
// 3. 通过await操作等待所有任务结束，也就是 countDown被调用10次
latch.await();
System.out.println("所有任务都已经完成了");
}
}
8. ConcurrentHashMap
多线程环境下HashMap线程不安全，使用哈希表（Hashtable）就在关键方法上添加synchronized。
-
ConcurrentHashMap的读是否要加锁？
读操作没有加锁，目的是为了进一步降低锁冲突的概率，为了保证读到刚修改的数据，搭配了volatile关键字。 -
介绍ConcurrentHashMap的锁分段技术？
把若干个哈希桶分成一个段，针对每个段分别加锁，这个是Java1.7中采取的技术，Java1.8不再使用，
8.1 ConcurrentHashMap（Java1.8）的改进
-
缩小了锁的粒度
在Hashtable，直接在方法上使用synchronized，就相当于是对this加锁，此时尝试修改两个不同链表上的元素，都会触发锁冲突。如果修改两个不同链表上的元素，就不涉及到线程安全，修改不同变量。如果修改是同一个链表上的元素，就可能出现线程安全问题。
ConcurrentHashMap 就是把锁变小了，给每个链表都发了一把锁，此时，不是操作同一个链表的锁，就不会产生锁冲突。 不会产生更多的空间代价，因为Java中任何一个对象都可以直接作为锁对象，本身哈希表中，就得有数组，数组的元素都是已经存在的（每个链表的头节点作为加锁对象即可）。
锁桶（hash表也称为hash桶），构成了一个类似于桶，每个链表就是构成桶的一个木板，所谓锁桶就是针对每个木板（每个链表）进行分别加锁的。 -
充分的使用了CAS原子操作，减少一些加锁
-
针对扩容操作的优化：扩容是一个重量操作。负载因子，描述了每个桶上平均有多少个元素，0.75是负载因子默认的扩容阈值，不是负载因子本体。负载因子是计算出来的：拿着实际的元素个数 / 数组的长度（桶的个数），这个值和扩容阈值进行比较，看是否需要扩容。
- 如果太长，1.变成树（长度不平均的情况），2.扩容。
- 创建一个更大的数组，把旧的hash表的元素都给搬运到（删除/插入）新的数组上，如果hash表本身元素非常多，这里扩容操作就会消耗很长的时间。
- ** HashMap的扩容操作是梭哈，在某次插入元素的操作中，整体就进行了扩容。而ConcurrentHashMap，每次操作都只搬运一部分元素。**
- 即在扩容的过程中，同时存在两份哈希表，一份新的一份旧的：插入操作：直接往新的上插入；删除操作：新的旧的都是直接删除；查找操作：新的和旧的都得查询一下。