【多线程】进阶
目录
一、CAS
什么是 CAS
CAS 伪代码
CAS 有哪些应用
实现原子类
CAS 是怎么实现的
如何通过 CAS 实现的原子类
CAS 的 ABA 问题
什么是 ABA 问题
ABA 问题引来的 BUG
正常的过程
异常的过程
解决方案
📝相关面试题
二、JUC(java.util.concurrent)的常见类
Callable 接口
理解 Callable
理解 FutureTask
ReentrantLock
ReentrantLock 和 synchronized 的区别:
原子类
线程池
信号量 Semaphore
理解信号量
CountDownLatch
📝相关面试题
三、线程安全的集合类
多线程环境使用 ArrayList
多线程环境使用队列
多线程环境使用哈希表
📝相关面试题
一、CAS
什么是 CAS
全称 Compare and swap ,字面意思就是 “比较并交换”,一个 CAS 涉及到以下操作:
我们假设内存中的原数据 V,旧的预期值 A,需要修改的新值 B
1️⃣比较 A 与 V 是否相等。(比较)
2️⃣如果比较相等,将 B 写入 V。(交换)
3️⃣返回操作是否成功。
〰️比较内存和 CPU 寄存器中的内容,如果发现相同,就进行交换(交换的是内存和另一个寄存器的内容)。一个内存的数据和两个寄存器中的数据进行操作(寄存器 1 和寄存器 2),比较内存和寄存器 1 中的值是否相等,如果不相等,就无事发生,如果相等,就交换内存和寄存器 2 的值(此处一般只是关心,内存交换后的内容,不关心寄存器 2 交换后的内容),虽然叫做 "交换" 实际上,希望达成的效果是 “赋值”。
CAS 伪代码
下面写的代码不是原子的,真实的 CAS 是⼀个原子的硬件指令完成的。 这个伪代码只是辅助理解 CAS 的工作流程,且下面的伪代码其实是有一条 CPU 指令完成的。
boolean CAS(address, expectValue, swapValue) {
if (&address == expectedValue) {
&address = swapValue;
return true;
} return false;
}
CAS 的关键不在于这个逻辑是干啥,而是在于,通过 "一个CPU指令"(原子的)完成了上述一系列的操作,因此 CAS 就能给编写多线程代码,带来新的思路〰️“无锁化编程”
CAS 有哪些应用
实现原子类
int/long 在进行➕➕、➖➖的时候(会经历 load、add、save 三步)都不是原子的,然而基于 CAS 实现的原子类,对 int/Iong 等这些类型进行了封装,从而可以原子的完成 ➕➕、➖➖ 等操作。
原子类,在Java标准库中,也有现成的实现。标准库中提供了 java.util.concurrent.atomic 包,里面的类都是基于这种方式来实现的。典型的就是 Atomiclnteger 类,其中的 getAndIncrement 相当i➕➕ 操作。
👁🗨➕➕操作的线程不安全代码
public class Demo36 {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
count++;
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
count++;
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("count = " + count);
}
}
👁🗨使用 Atomiclnteger 类实现线程安全并且不用加锁的代码
import java.util.concurrent.atomic.AtomicInteger;
public class Demo36 {
// 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++) {
count.getAndIncrement(); // count++;
// count.incrementAndGet(); //++count;
// count.getAndIncrement(); //count--;
// count.decrementAndGet(); //--count;
// count.getAndAdd(10); //count+= 10;
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
// count++;
count.getAndIncrement(); // count++;
}
});
t1.start();
t2.start();
t1.join();
t2.join();
//通过 count.get() 拿到原子类内部持有的真实数据
System.out.println("count = " + count);
}
}
其它类在 Java 文档中都有,附下图
CAS 是怎么实现的
针对不同的操作系统,JVM 用到了不同的 CAS 实现原理,简单来讲:
🔹java 的 CAS 利用的是 unsafe 这个类提供的 CAS 操作;
🔹unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg;
🔹Atomic::cmpxchg 的实现使用了汇编的 CAS 操作,并使用 cpu 硬件提供的 lock 机制保证其原子性。
简而言之,是因为硬件予以了支持,软件层面才能做到
如何通过 CAS 实现的原子类
分析给出的伪代码
📷图解
假设两个线程同时调用 getAndIncrement
1️⃣两个线程都读取 value 的值到 oldValue 中.(oldValue 是一个局部变量,在栈上.每个线程有自己的栈)
2️⃣线程 2 先执行 CAS 操作.由于 oldValue 和 value 的值相同,直接进行对 value 赋值
注意:
CAS 是直接读写内存的,而不是操作寄存器.
CAS 的读内存,比较,写内存操作是一条硬件指令,是原子的.
3️⃣线程 1 再执行 CAS 操作,第一次 CAS 的时候发现 oldValue 和 value 不相等,不能进行赋值.因此需要进入循环.
在循环里重新读取 value 的值赋给 oldValue
4️⃣线程 1 接下来第二次执行 CAS,此时 oldValue 和 value 相同,于是进行赋值操作.
5️⃣线程 1 和线程 2 返回各自的 oldValue 的值即可.
通过形如上述代码就可以实现一个原子类.不需要使用重量级锁,就可以高效的完成多线程的自增操作.
本来 check and set 这样的操作在代码角度不是原子的.但是在硬件层面上可以让一条指令完成这个
操作,也就变成原子的了.
上面的这个过程,类似于,网购一个东西,确认收货的过程。比如买一个笔记本电脑/手机,有的人,直接就拆了开始使用了(有可能买到了二手机/翻新机),也有的人,会先做详细的检查,检查商品的序列号,去官网上对比。如果发现机器没有问题,才真正进行后续的使用(没有识别到别人使用的痕迹),如果发现机器有问题,有别人使用的痕迹,就得及时进行售后。
CAS 的 ABA 问题
什么是 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 呢?
到这一步,t1 线程无法区分当前这个变量始终是 A,还是经历了一个变化过程.
这就好比,我们买一个手机,无法判定这个手机是刚出厂的新手机,还是别人用引旧了,又翻新过的手机
ABA 问题引来的 BUG
大部分的情况下,t2 线程这样的一个反复横跳改动,对于 t1 是否修改 num 是没有影响的.但是不排除一些特殊情况.
假设滑稽老哥有 1000 存款.滑稽想从 ATM 取 500 块钱.取款机创建了两个线程,并发的来执行 -500 操作.
我们期望一个线程执行 -500 成功,另一个线程 -500 失败.
如果使用 CAS 的方式来完成这个扣款过程就可能出现问题.
正常的过程
存款 1000.线程 1 获取到当前存款值为 1000,期望更新为 500;线程 2 获取到当前存款值为1000,期望更新为 500.
线程 1 执行扣款成功,存款被改成 500.线程 2 阻塞等待中
轮到线程 2 执行了,发现当前存款为 500,和之前读到的 1000 不相同,执行失败.
异常的过程
存款 1000.线程 1 获取到当前存款值为 1000,期望更新为 500;线程 2 获取到当前存款值为 1000,期望更新为 500.
线程 1 执行扣款成功,存款被改成 500.线程 2 阻塞等待中,
在线程 2 执行之前,滑稽的朋友正好给滑稽转账 500,账户余额变成 1000!!
轮到线程 2 执行了,发现当前存款为 1000,和之前读到的 1000 相同,再次执行扣款操作
这个时候,扣款操作被执行了两次!!!都是 ABA 问题搞的鬼!!
解决方案
给要修改的值,引入版本号.在 CAS 比较数据当前值和旧值的同时,也要比较版本号是否符合预期.
●CAS 操作在读取旧值的同时,也要读取版本号.
●真正修改的时候,
。如果当前版本号和读到的版本号相同,则修改数据,并把版本号 +1.
。如果当前版本号高于读到的版本号.就操作失败(认为数据已经被修改过了).
这就好比,判定这个手机是否是翻新机,那么就需要收集每个手机的数据,第一次挂在电商网站上的手机记为版本 1,以后每次这个手机出现在电商网站上,就把版本号进行递增.这样如果买家不在意这是翻新机,就买.如果买家在意,就可以直接略过.
⬆️对比理解上面的转账例子
假设滑稽老哥有 1000 存款.滑稽想从 ATM 取 500 块钱.取款机创建了两个线程,并发的来执行 -500 操作.
我们期望一个线程执行 -500 成功,另一个线程 -500失败.
为了解决 ABA 问题,给余额搭配一个版本号,初始设为 1.
存款 1000.线程 1 获取到存款值为 1000,版本号为 1,期望更新为 500;线程 2 获取到存款值为1000,版本号为 1,期望更新为500.
线程 1 执行扣款成功,存款被改成 500,版本号改为 2.线程 2 阻塞等待中.
在线程 2 执行之前,滑稽的朋友正好给滑稽转账 500,账户余额变成1000,版本号变成 3.
轮到线程 2 执行了,发现当前存款为 1000,和之前读到的 1000 相同,但是当前版本号为 3,之前读到的版本号为 1,版本小于当前版本,认为操作失败.
实际开发中,一般很少直接使用 CAS,都是大佬封装好了,直接进行使用现成的操作,因为 CAS本身使用起来有点复杂的.
在 Java 标准库中提供了 AtomicStampedReference<E> 类.这个类可以对某个类进行包装,在内
部就提供了上面描述的版本管理功能
关于 AtomicStampedReference<E> 的具体用法此处不再展开,有需要的同学自行查找文档了解使用方法即可.
📝相关面试题
1️⃣讲解下你自己理解的 CAS 机制
全称Compare and swap,即 "比较并交换" 相当于通过一个原子的操作,同时完成 "读取内存,比较是否相等,修改内存" 这三个步骤.本质上需要 CPU 指令的支撑.
2️⃣ABA 问题怎么解决
给要修改的数据引入版本号.在 CAS 比较数据当前值和旧值的同时,也要比较版本号是否符合预期.如果发现当前版本号和之前读到的版本号一致,就真正执行修改操作,并让版本号自增;如果发现当前版本号比之前读到的版本号大,就认为操作失败.
二、JUC(java.util.concurrent)的常见类
Callable 接口
Callable 是一个 interface.相当于把线程封装了一个 "返回值".方便程序猿借助多线程的方式计算结
果.
👁🗨创建线程计算1+2+3++1000,不使用 Callable 版本
class Demo37 {
private static int result;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(() -> {
int sum = 0;
for (int i = 0; i < 1000; i++) {
sum += i;
}
result = sum;
});
t.start();
t.join();
System.out.println("result =" + result);
}
}
👁🗨创建线程计算1+2+3++1000,使用Callable版本
▪️创建一个匿名内部类,实现 Callable 接口.Callable 带有泛型参数.泛型参数表示返回值的类型.
▪️重写 Callable 的 call 方法,完成累加的过程.直接通过返回值返回计算结果.
▪️把 callable 实例使用 FutureTask 包装一下.
▪️创建线程,线程的构造方法传入 FutureTask.此时新线程就会执行 FutureTask 内部的 Callable的 call 方法,完成计算.计算结果就放到了 FutureTask 对象中.
▪️在主线程中调用 futureTask.get() 能够阻塞等待新线程计算完毕.并获取到 FutureTask 中的结果.
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
public class Demo37 {
public static void main(String[] args) throws ExecutionException, InterruptedException {
Callable<Integer> callable = new Callable<Integer>() {
@Override
public Integer call() throws Exception {
int sum = 0;
for (int i = 1; i <= 1000; i++) {
sum += i;
}
return sum;
}
};
FutureTask<Integer> futureTask = new FutureTask<>(callable);
Thread t = new Thread(futureTask);
t.start();
System.out.println(futureTask.get());
}
}
理解 Callable
类似于 Runnable ,可以表示有一个具体的任务,通过 run 方法来描述任务的内容
🏸Callable 和 Runnable 相对,都是描述一个 "任务".Callable描述的是带有返回值的任务,Runnable描述的是不带返回值的任务.
🏸Callable 通常需要搭配 FutureTask 来使用.FutureTask 用来保存 Callable 的返回结果.因为
Callable 往往是在另一个线程中执行的,啥时候执行完并不确定.
🏸FutureTask 就可以负责这个等待结果出来的工作.
理解 FutureTask
想象去吃麻辣烫.当餐点好后,后厨就开始做了.同时前台会给你一张"小票".这个小票就是
FutureTask.后面我们可以随时凭这张小票去查看自己的这份麻辣烫做出来了没.
ReentrantLock
可重入互斥锁.和 synchronized 定位类似,都是用来实现互斥效果,保证线程安全
ReentrantLock 也是可重入锁."Reentrant" 这个单词的原意就是 "可重入"
ReentrantLock 的用法:经典风格的锁,通过 lock 和 unlock 方法来完成加锁解锁
▫️lock():加锁,如果获取不到锁就死等.
▫️trylock(超时时间):加锁,如果获取不到锁,等待一定的时间之后就放弃加锁.
▫️unlock():解锁
import java.util.concurrent.locks.ReentrantLock;
public class Demo38 {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
ReentrantLock lock = new ReentrantLock();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
lock.lock();
count++;
lock.unlock();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
lock.lock();
count++;
lock.unlock();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("count = " + count);
}
}
实际开发中,大多数情况下,使用 synchronized 即可.
ReentrantLock 相比 synchronized 还是有一些区别差异的.
ReentrantLock 和 synchronized 的区别:
🌀synchronized 是一个关键字,是 JVM 内部实现的(基于 C++ 实现).ReentrantLock 是标准库的一个类,在 JVM 外实现的(基于 Java 代码实现).
🌀synchronized 使用时不需要手动释放锁.ReentrantLock 使用时需要手动释放.使用起来更灵活,但是也容易遗漏 unlock.可以把 unlock 放到 finally 中.
💠synchronized 在申请锁失败时,会死等.ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.在加锁失败的时候不会阻塞,而是直接返回,通过返回值来反馈是加锁成功还是失败.
💠synchronized 是非公平锁,ReentrantLock 默认是非公平锁.可以通过构造方法传入一个 true 开启公平锁模式.
💠更强大的唤醒机制.synchronized 是通过 Object 的 wait/notify 实现等待-唤醒.每次唤醒的是一个随机等待的线程.ReentrantLock 搭配 Condition 类实现等待-唤醒,可以更精确控制唤醒某个指定的线程.
如何选择使用哪个锁?
锁竞争不激烈的时候,使用 synchronized,效率更高,自动释放更方便.
锁竞争激烈的时候,使用 ReentrantLock,搭配 trylock 更灵活控制加锁的行为,而不是死等.
如果需要使用公平锁,使用 ReentrantLock.
原子类
原子类内部用的是 CAS 实现,所以性能要比加锁实现 ➕➕ 高很多。原子类有以下几个
AtomicBoolean
Atomiclnteger
AtomiclntegerArray
AtomicLong
AtomicReference
AtomicStampedReference
以 Atomiclnteger 举例,常见方法有
addAndGet(int delta); i += delta;
decrementAndGet(); --i;
getAndDecrement(); i--;
incrementAndGet(); ++i;
getAndIncrement(); i++;
详见文章第一部分内容
线程池
详细内容请跳转到此篇文章进行查看
信号量 Semaphore
信号量,用来表示 "可用资源的个数". 本质上就是⼀个计数器.
理解信号量
可以把信号量想象成是停车场的展示牌:当前有车位 100 个.表示有 100 个可用资源
当有车开进去的时候,就相当于申请一个可用资源,可用车位就 -1(这个称为信号量的 P 操作)
当有车开出来的时候,就相当于释放一个可用资源,可用车位就 +1(这个称为信号量的 V 操作)
如果计数器的值已经为 0 了,还尝试申请资源,就会阻塞等待,直到有其他线程释放资源
Semaphore 的 PV 操作中的加减计数器操作都是原子的,可以在多线程环境下直接使用.
👁🗨代码示例
import java.util.concurrent.Semaphore;
public class Demo39 {
public static void main(String[] args) throws InterruptedException {
Semaphore semaphore = new Semaphore(3);
semaphore.acquire();
System.out.println("申请一个资源");
semaphore.acquire();
System.out.println("申请一个资源");
semaphore.acquire();
System.out.println("申请一个资源");
semaphore.release();
System.out.println("释放一个资源");
semaphore.acquire();
System.out.println("申请一个资源");
}
}
用信号量还可以实现加锁解锁效果🔒🔓
import java.util.concurrent.Semaphore;
import java.util.concurrent.locks.ReentrantLock;
public class Demo38 {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
ReentrantLock lock = new ReentrantLock();
Semaphore semaphore = new Semaphore(1);
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
// lock.lock();
try {
semaphore.acquire();
count++;
semaphore.release();
} catch (InterruptedException e) {
e.printStackTrace();
}
// lock.unlock();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
// lock.lock();
try {
semaphore.acquire();
count++;
semaphore.release();
} catch (InterruptedException e) {
e.printStackTrace();
}
// lock.unlock();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("count = " + count);
}
}
CountDownLatch
同时等待 N 个任务执行结束.
好像跑步比赛,10 个选手依次就位,哨声响才同时出发;所有选手都通过终点,才能公布成绩。
很多时候,需要把一个大的任务,拆成多个小任务,通过 多线程/线程池 执行.
那么如何衡量,所有的任务都执行完毕了?
🔸构造 CountDownLatch 实例,初始化 20 表示有 20 个任务需要完成.
🔸每个任务执行完毕,都调用 countDownLatch.countDown().在 CountDownLatch 内部的计数器同时自减.
🔸主线程中使用 countDownLatch.await(); 阻塞等待所有任务执行完毕.相当于计数器为 0 了.
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class Demo40 {
public static void main(String[] args) throws InterruptedException {
ExecutorService executorService = Executors.newFixedThreadPool(4);
//构造方法的数字,就是拆分出来的任务个数
CountDownLatch countDownLatch = new CountDownLatch(20);
for (int i = 0; i < 20; i++) {
int id = i;
executorService.submit(() -> {
System.out.println("下载任务 " + id + "");
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("下载任务 " + id + " 结束执行");
//完毕 over
countDownLatch.countDown();
});
}
// 当 countDownLatch 收到了 20 个 “完成”,所有的任务就都完成了
// await => all wait
// await 这个词也是计算机术语,在python / js 意思是 async wait(异步等待)
countDownLatch.await();
System.out.println("所有任务都完成");
}
}
📝相关面试题
1️⃣线程同步的方式有哪些?
synchronized, ReentrantLock, Semaphore 等都可以用于线程同步.
2️⃣为什么有了 synchronized 还需要 juc 下的 lock?
以 juc 的 ReentrantLock 为例,
●synchronized 使用时不需要手动释放锁.ReentrantLock 使用时需要手动释放.使用起来更灵活.
●synchronized 在申请锁失败时,会死等.ReentrantLock 可以通过 trylock 的方式等待一段时间就放弃.
●synchronized 是非公平锁,ReentrantLock 默认是非公平锁.可以通过构造方法传入一个 true 开启公平锁模式.
●synchronized 是通过 Object 的 wait/notify 实现等待-唤醒.每次唤醒的是一个随机等待的线程.
ReentrantLock 搭配 Condition 类实现等待-唤醒,可以更精确控制唤醒某个指定的线程
3️⃣AtomicInteger 的实现原理是什么?
基于 CAS 机制. 伪代码如下:
执行过程参考上面 CAS "有哪些应用" 部分.
4️⃣信号量听说过么?之前都用在过哪些场景下?
信号量,用来表示 "可用资源的个数".本质上就是一个计数器
使用信号量可以实现 "共享锁",比如某个资源允许 3 个线程同时使用,那么就可以使用 P 操作作为加锁,V 操作作为解锁,前三个线程的 P 操作都能顺利返回,后续线程再进行 P 操作就会阻塞等待,直到前面的线程执行了 V 操作.
5️⃣解释⼀下 ThreadPoolExecutor 构造方法的参数的含义
参考 ThreadPoolExecutor 章节https://blog.csdn.net/2301_80141037/article/details/146104441?spm=1001.2014.3001.5502
三、线程安全的集合类
原来的集合类,大部分都不是线程安全的
Vector,Stack,HashTable 是线程安全的(内置了 synchronized 无脑加锁,所以不建议用),其他的集合类不是线程安全的
多线程环境使用 ArrayList
1️⃣自己使用同步机制 (synchronized 或者 ReentrantLock),自己加锁
前面做过很多相关的讨论了.此处不再展开.
2️⃣Collections.synchronizedList(new ArrayList);
synchronizedList 是标准库提供的⼀个基于 synchronized 进行线程同步的 List. synchronizedList 的关键操作上都带有 synchronized
如果需要使用 ArrayList/LinkedList 这样的结构,在标准库中提供了一个带锁的 List
3️⃣使用 CopyOnWriteArrayList
CopyOnWrite 容器即写时复制的容器。没有加锁,通过写时复制来实现线程安全。
🥛当我们往一个容器添加元素的时候,不直接往当前容器添加,而是先将当前容器进行 Coy,复制出一个新的容器,然后新的容器里添加元素,
🥛添加完元素之后,再将原容器的引用指向新的容器。
这样做的好处是我们可以对 CopyOnWrite 容器进行并发的读,而不需要加锁,因为当前容器不会添加任何元素。
所以 CopyOnWrite 容器也是一种读写分离的思想,读和写不同的容器。
优点:
在读多写少的场景下,性能很高,不需要加锁竞争.因此,当前写时拷贝机制主要就是用来应对多个线程读,一个线程写这样的场景.
缺点:
1.占用内存较多.
2.新写的数据不能被第一时间读取到.并且如果是针对多个线程同时写的情况,写实拷贝机制就难以应对
多线程环境使用队列
1.ArrayBlockingQueue
基于数组实现的阻塞队列
2.LinkedBlockingQueue
基于链表实现的阻塞队列
3.PriorityBlockingQueue
基于堆实现的带优先级的阻塞队列
4.TransferQueue
最多只包含一个元素的阻塞队列
多线程环境使用哈希表
HashMap 本身不是线程安全的.
在多线程环境下使用哈希表可以使用:
●Hashtable(不推荐)
●ConcurrentHashMap(Java方向top5 超高频面试题)🎯🎯🎯
此处的这个数据结构,相比于 HashMap 和 Hashtable 来说,改进力度是非常大的
1️⃣优化了锁的粒度[最核心]
Hashtable只是简单的把关键方法加上了 synchronized 关键字
这相当于直接针对 Hashtable 对象本身加锁.使整个哈希表对象就是一把锁,任何一个针对这个哈希表的操作都会触发锁竞争
🔹如果多线程访问同一个 Hashtable 就会直接造成锁冲突.
ConcurrentHashMap 是给每个 hash 表中的 "链表" 进行加锁.(不是一把锁,而是多把锁)-"锁桶"
🔸写操作加锁的方式仍然是用 synchronized,但是不是锁整个对象,而是 "锁桶"(用每个链表的头结点作为锁对象),大大降低了锁冲突的概率.
2️⃣ConcurrentHashMap 引入了 CAS 原子操作,针对像修改 size 这样的操作,直接借助 CAS 完成,并不会加锁.
🔹size 属性(元素的个数)也是通过 synchronized 来控制同步,也是比较慢的.
🔸充分利用 CAS 特性. 比如 size 属性通过 CAS 来更新. 避免出现重量级锁的情况.
3️⃣针对读操作,做了特殊处理.
🔸读操作没有加锁(但是使用了 volatile 保证从内存读取结果),只对写操作进行加锁.确保读操作不会读到 "修改一半" 的数据.
4️⃣针对 hash 表的扩容,进行了特殊的优化.
🔹普通 hash 表一旦触发扩容,需要创建新的 hash 表,把元素都搬运过去,就由该线程完成整个扩容过程.在一次 put 就完成了,这个过程会涉及到大量的元素拷贝,效率会非常低.
🔸优化了扩容方式: 化整为零
▪️发现需要扩容的线程,只需要创建一个新的数组,同时只搬几个元素过去.
▪️扩容期间,新老数组同时存在.
▪️后续每个来操作 ConcurrentHashMap 的线程,都会参与搬家的过程.每个操作负责搬运一小部分元素.
▪️搬完最后一个元素再把老数组删掉.
▪️这个期间,插入只往新数组加.
▪️这个期间,查找需要同时查新数组和老数组.
📝相关面试题
1️⃣ConcurrentHashMap 的读是否要加锁,为什么?
读操作没有加锁. 目的是为了进一步降低锁冲突的概率. 为了保证读到刚修改的数据,搭配了 volatile 关键字.
2️⃣介绍下 ConcurrentHashMap 的锁分段技术?
这个是 Java1.7 中采取的技术. Java1.8 中已经不再使用了. 简单的说就是把若干个哈希桶分成一个 "段" (Segment),针对每个段分别加锁.
目的也是为了降低锁竞争的概率. 当两个线程访问的数据恰好在同一个段上的时候,才触发锁竞争.
3️⃣ConcurrentHashMap 在 jdk1.8 做了哪些优化?
取消了分段锁,直接给每个哈希桶(每个链表)分配了一个锁(就是以每个链表的头结点对象作为锁对象).
将原来 数组 + 链表 的实现方式改进成 数组 + 链表 / 红黑树 的方式. 当链表较长的时候(大于等于 8 个元素)就转换成红黑树.
4️⃣Hashtable 和 HashMap、ConcurrentHashMap 之间的区别?
HashMap: 线程不安全. key 允许为 null.
Hashtable: 线程安全. 使用 synchronized 锁 Hashtable 对象,效率较低. key 不允许为 null.
ConcurrentHashMap: 线程安全. 使用 synchronized 锁每个链表头结点,锁冲突概率低,充分利用 CAS 机制. 优化了扩容方式. key 不允许为 null.