面试官：ConcurrentHashMap真的线程安全吗？

拼搏现实的明天。 2023-01-16 04:54 71阅读 0赞

**关注“****java后端技术全栈****”**

**回复“000”获取优质面试资料**

## 前言 ##

没有真正实践过的朋友，总是认为把`HashMap`改为`ConcurrentHashMap`，就完美解决并发了呀。或者使用写时复制的`CopyOnWriteArrayList`，性能更佳呀！技术言论虽然自由。

![077275602c066924a88478e56d790b71.png][]

但面对魔鬼面试官时，我们更在乎的是这些真的正确吗？

## 线程重用导致用户信息错乱 ##

生产环境中，有时获取到的用户信息是别人的。查看代码后，发现是使用了`ThreadLocal`缓存获取到的用户信息。

`ThreadLocal`适用于变量在线程间隔离，而在方法或类间共享的场景。若用户信息的获取比较昂贵（比如从DB查询），则在`ThreadLocal`中缓存比较合适。问题来了，为什么有时会出现用户信息错乱？

### 1.1 案例 ###

使用`ThreadLocal`存放一个`Integer`值，代表需要在线程中保存的用户信息，初始`null`。先从`ThreadLocal`获取一次值，然后把外部传入的参数设置到`ThreadLocal`中，模拟从当前上下文获取用户信息，随后再获取一次值，最后输出两次获得的值和线程名称。

[![ac14204263375697745968cd7d62d9e5.png][]][ac14204263375697745968cd7d62d9e5.png 1]

固定思维认为，在设置用户信息前第一次获取的值始终是`null`，但要清楚程序运行在`Tomcat`，执行程序的线程是`Tomcat`的工作线程，其基于线程池。而线程池会重用固定线程，一旦线程重用，那么很可能首次从`ThreadLocal`获取的值是之前其他用户的请求遗留的值。这时，`ThreadLocal`中的用户信息就是其他用户的信息。

### 1.2 bug 重现 ###

在配置文件设置`Tomcat`参数-工作线程池最大线程数设为1，这样始终是同一线程在处理请求：

server.tomcat.max-threads=1

先让用户1请求接口，第一、第二次获取到用户ID分别是null和1，符合预期。

![777c0f52c4f9f7881918dca14afe9519.png][]

用户2请求接口，`bug复现`！第一、第二次获取到用户ID分别是1和2，显然第一次获取到了用户1的信息，因为Tomcat线程池重用了线程。两次请求线程都是同一线程：`http-nio-45678-exec-1`。

![c880e2b40ba8ced8c779da3220968a04.png][]

写业务代码时，首先要理解代码会跑在什么线程上：

*  Tomcat服务器下跑的业务代码，本就运行在一个多线程环境（否则接口也不可能支持这么高的并发），并不能认为没有显式开启多线程就不会有线程安全问题
 *  线程创建较昂贵，所以Web服务器会使用线程池处理请求，线程会被重用。使用类似ThreadLocal工具存放数据时，需注意在代码运行完后，显式清空设置的数据。

### 1.3 解决方案 ###

在`finally`代码块显式清除`ThreadLocal`中数据。即使新请求过来，使用了之前的线程，也不会获取到错误的用户信息。修正后代码：

![6aa5eb9a7143959164307c6d45fef756.png][]

`ThreadLocal`利用独占资源的解决线程安全问题，若就是要资源在线程间共享怎么办？

就需要用到`线程安全的容器`。

使用了线程安全的并发工具，并不代表解决了所有线程安全问题。

### 1.4 ThreadLocalRandom 可将其实例设置到静态变量，在多线程下重用吗？ ###

`current()`的时候初始化一个初始化种子到线程，每次`nextseed`再使用之前的种子生成新的种子：

UNSAFE.putLong(t = Thread.currentThread(), SEED,
    r = UNSAFE.getLong(t, SEED) + GAMMA);

如果你通过主线程调用一次`current`生成一个`ThreadLocalRandom`实例保存，那么其它线程来获取种子的时候必然取不到初始种子，必须是每一个线程自己用的时候初始化一个种子到线程。可以在nextSeed设置一个断点看看：

UNSAFE.getLong(Thread.currentThread(),SEED);

## ConcurrentHashMap真的安全吗？ ##

我们都知道`ConcurrentHashMap`是个线程安全的哈希表容器，但它仅保证提供的原子性读写操作线程安全。

### 2.1 案例 ###

有个含900个元素的Map，现在再补充100个元素进去，这个补充操作由10个线程并发进行。

开发人员误以为使用`ConcurrentHashMap`就不会有线程安全问题，于是不加思索地写出了下面的代码：在每一个线程的代码逻辑中先通过`size`方法拿到当前元素数量，计算`ConcurrentHashMap`目前还需要补充多少元素，并在日志中输出了这个值，然后通过`putAll`方法把缺少的元素添加进去。

为方便观察问题，我们输出了这个Map一开始和最后的元素个数。

![bc513dac42f37ed63c38e0e9b7688d5f.png][]

访问接口:

![beb814d474a69359995ad44bdb2d3d27.png][]

分析日志输出可得：

*  [初始大小900符合预期，还需填充100个元素][900_100]
 *  `worker13`线程查询到当前需要填充的元素为49，还不是100的倍数
 *  最后`HashMap`的总项目数是1549，也不符合填充满1000的预期

### 2.2 bug 分析 ###

`ConcurrentHashMap`就像是一个大篮子，现在这个篮子里有900个桔子，我们期望把这个篮子装满1000个桔子，也就是再装100个桔子。有10个工人来干这件事儿，大家先后到岗后会计算还需要补多少个桔子进去，最后把桔子装入篮子。

`ConcurrentHashMap`这篮子本身，可以确保多个工人在装东西进去时，不会相互影响干扰，但无法确保工人A看到还需要装100个桔子但是还未装时，工人B就看不到篮子中的桔子数量。你往这个篮子装100个桔子的操作不是原子性的，在别人看来可能会有一个瞬间篮子里有964个桔子，还需要补36个桔子。

`ConcurrentHashMap`对外提供能力的限制：

*  使用不代表对其的多个操作之间的状态一致，是没有其他线程在操作它的。如果需要确保需要手动加锁
 *  诸如size、isEmpty和`containsValue`等聚合方法，在并发下可能会反映`ConcurrentHashMap`的中间状态。因此在并发情况下，这些方法的返回值只能用作参考，而不能用于流程控制。显然，利用size方法计算差异值，是一个流程控制
 *  诸如putAll这样的聚合方法也不能确保原子性，在putAll的过程中去获取数据可能会获取到部分数据

### 2.3 解决方案 ###

整段逻辑加锁：

![43073eaa605b109dd9f9918dff06e811.png][]

只有一个线程查询到需补100个元素，其他9个线程查询到无需补，最后Map大小1000。

![2b187727fc6e06a5eb2c0fabf4d337ae.png][]

既然使用`ConcurrentHashMap`还要全程加锁，还不如使用`HashMap`呢？不完全是这样。

`ConcurrentHashMap`提供了一些原子性的简单复合逻辑方法，用好这些方法就可以发挥其威力。这就引申出代码中常见的另一个问题：在使用一些类库提供的高级工具类时，开发人员可能还是按照旧的方式去使用这些新类，因为没有使用其真实特性，所以无法发挥其威力。

## 知己知彼，百战百胜 ##

### 3.1 案例 ###

使用Map来统计Key出现次数的场景。

*  [使用`ConcurrentHashMap`来统计，Key的范围是10][ConcurrentHashMap_Key_10]
 *  使用最多10个并发，循环操作1000万次，每次操作累加随机的Key
 *  如果Key不存在的话，首次设置值为1。

#### `show me code`: ####

[![ef14ab96a6eaaf1f44b0b49289d4be55.png][]][ef14ab96a6eaaf1f44b0b49289d4be55.png 1]

有了上节经验，我们这直接锁住Map，再做

*  判断
 *  读取现在的累计值
 *  \+1
 *  保存累加后值

这段代码在功能上的确毫无没有问题，但却无法充分发挥`ConcurrentHashMap`的性能，优化后：

![78476dd128dd55c3dc3e5e71cf8989c4.png][]

`ConcurrentHashMap`的原子性方法`computeIfAbsent`做复合逻辑操作，判断K是否存在V，若不存在，则把Lambda运行后结果存入Map作为V，即新创建一个LongAdder对象，最后返回V

因为`computeIfAbsent`返回的V是`LongAdder`，是个线程安全的累加器，可直接调用其`increment`累加。

这样在确保线程安全的情况下达到极致性能，且代码行数骤减。

### 3.2 性能测试 ###

使用`StopWatch`测试两段代码的性能，最后的断言判断Map中元素的个数及所有`V`的和是否符合预期来校验代码正确性

[![9cb1e645f2c12eecd6701ced02c559c8.png][]][9cb1e645f2c12eecd6701ced02c559c8.png 1]

性能测试结果：

![707b193dbaae7a7a809ca698f0999c25.png][]

比使用锁性能提升至少5倍。

### 3.3 computeIfAbsent高性能之道 ###

Java的`Unsafe`实现的`CAS`。

它在JVM层确保写入数据的原子性，比加锁效率高：

static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
                                        Node<K,V> c, Node<K,V> v) {
        return U.compareAndSetObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
    }

所以不要以为只要用了`ConcurrentHashMap`并发工具就是高性能的高并发程序。

#### 辨明 computeIfAbsent、putIfAbsent ####

*  当Key存在的时候，如果Value获取比较昂贵的话，putIfAbsent就白白浪费时间在获取这个昂贵的Value上（这个点特别注意）
 *  Key不存在的时候，putIfAbsent返回null，小心空指针，而computeIfAbsent返回计算后的值
 *  当Key不存在的时候，putIfAbsent允许put null进去，而computeIfAbsent不能，之后进行containsKey查询是有区别的（当然了，此条针对HashMap，ConcurrentHashMap不允许put null value进去）

### 3.4 CopyOnWriteArrayList 之殇 ###

再比如一段简单的非 DB操作的业务逻辑，时间消耗却超出预期时间，在修改数据时操作本地缓存比回写DB慢许多。原来是有人使用了`CopyOnWriteArrayList`缓存大量数据，而该业务场景下数据变化又很频繁。

`CopyOnWriteArrayList`虽然是一个线程安全版的ArrayList，但其每次修改数据时都会复制一份数据出来，所以只适用读多写少或无锁读场景。

所以一旦使用`CopyOnWriteArrayList`，一定是因为场景适宜而非炫技。

#### CopyOnWriteArrayList V.S 普通加锁ArrayList读写性能 ####

测试并发写性能:

![7f6c741490f09e68a5e57913cc2b6a8d.png][]

测试结果：高并发写，`CopyOnWriteArray`比同步`ArrayList`慢百倍:

![f562fc6be566e3e1b23745e6bbb29cd7.png][]

测试并发读性能:

![011fac87576c55420779e0323da78d42.png][]

测试结果：高并发读（100万次get操作），`CopyOnWriteArray`比同步`ArrayList`快24倍:

![07b0c7b26bd617d843edf722463b4124.png][]

高并发写时，`CopyOnWriteArrayList`为何这么慢呢？因为其每次add时，都用`Arrays.copyOf`创建新数组，频繁add时内存申请释放性能消耗大。

## 4 总结 ##

### 4.1 Don't !!! ###

*  不要只会用并发工具，而不熟悉线程原理
 *  不要觉得用了并发工具，就怎么都线程安全
 *  不熟悉并发工具的优化本质，就难以发挥其真正性能
 *  不要不结合当前业务场景，就随意选用并发工具，可能导致系统性能更差

### 4.2 Do !!! ###

*  认真阅读官方文档，理解并发工具适用场景及其各API的用法，并自行测试验证，最后再使用
 *  并发bug本就不易复现， 多自行进行性能压力测试

参考：http://e9ew9.cn/eReTs

**推荐阅读**

*  [MySQL的25个连环炮][MySQL_25]
 *  [线程池的12个连环炮][12]
 *  [并发编程基础的12个连环炮][12 1]
 *  [JVM的18个连环炮][JVM_18]
 *  [HashMap的31连环炮，我倒在第5个上][HashMap_31_5]  
    
 *  [Redis的43连环炮，试试你能扛住几个][Redis_43]
 *  [别不信，98%的程序员都是这样的][ef14ab96a6eaaf1f44b0b49289d4be55.png 1]
 *  [37个Dubbo 连环炮，能扛住几个？][ac14204263375697745968cd7d62d9e5.png 1]
 *  [限时免费下载，程序员必备书籍][9cb1e645f2c12eecd6701ced02c559c8.png 1]
    
    看完了，点个赞、在看，再走呗！

[077275602c066924a88478e56d790b71.png]: /images/20221022/cfdba2ab0f3d41938305ec03d164972f.png
[ac14204263375697745968cd7d62d9e5.png]: /images/20221022/4b0c228c325d46908173d1567103d6eb.png
[ac14204263375697745968cd7d62d9e5.png 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556bfeca22e2e8f834936af9f68bb7e34bc797c389f51c87d18dc6d51bd1aca5f9a62fd4d0&idx=1&mid=2247500565&scene=21&sn=72079f96d1e8669ff3b3ff5375147093#wechat_redirect
[777c0f52c4f9f7881918dca14afe9519.png]: /images/20221022/13b4c487c9fe4cedb61f6d3047786fe4.png
[c880e2b40ba8ced8c779da3220968a04.png]: /images/20221022/dc0b14951f494282b6961bd01697f302.png
[6aa5eb9a7143959164307c6d45fef756.png]: /images/20221022/246fbebcb5814a38a6be93cbc6996b39.png
[bc513dac42f37ed63c38e0e9b7688d5f.png]: /images/20221022/e9c011cc5d5c4e6a9ae5a79bc3b7ef3a.png
[beb814d474a69359995ad44bdb2d3d27.png]: /images/20221022/9cfa007ecc4a4a518304abbc54859a68.png
[900_100]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556a8dca22e39b284b1c9209291a21bbe37ee1eb83f54ade50a12e3d9db39795429c9a53f5&idx=1&mid=2247500390&scene=21&sn=88d2b6f0831dd0b1314c37a07c03c6d6#wechat_redirect
[43073eaa605b109dd9f9918dff06e811.png]: /images/20221022/13cfbaa5bad745b7b35ac273dc9eaffa.png
[2b187727fc6e06a5eb2c0fabf4d337ae.png]: /images/20221022/469e6d64e6e94acfab581e36cdefeb15.png
[ConcurrentHashMap_Key_10]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556938ca22e02e09da22b3097fe1552c742b62fbcb8d1ea8202980d0b74ea60f8657e18ca7&idx=1&mid=2247500243&scene=21&sn=ba006173b5dd36152bc4ae211ba617b4#wechat_redirect
[ef14ab96a6eaaf1f44b0b49289d4be55.png]: /images/20221022/42fb0bf874cf4968be7cc2d39058dab6.png
[ef14ab96a6eaaf1f44b0b49289d4be55.png 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd555753ca22de4522b62563737854b0359847f046b416df20cdfa099ea81d8e03c8bb22f4d1&idx=1&mid=2247499704&scene=21&sn=e3a867f360e8a8cccf8d79e0652c36c0#wechat_redirect
[78476dd128dd55c3dc3e5e71cf8989c4.png]: /images/20221022/95305d90f2884867a90d4f52ba168272.png
[9cb1e645f2c12eecd6701ced02c559c8.png]: /images/20221022/fda80b12eae147c5b21923c2c6a1f86c.png
[9cb1e645f2c12eecd6701ced02c559c8.png 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556a5fca22e349a9cc0d000aed257097046f7459c10cf822e15469979e1b617ca343a4093b&idx=2&mid=2247500468&scene=21&sn=d8a7349e02ad2a3289bb738b1de1d43f#wechat_redirect
[707b193dbaae7a7a809ca698f0999c25.png]: /images/20221022/f07b70f9eed74fc8a6c3aca2708e5cd6.png
[7f6c741490f09e68a5e57913cc2b6a8d.png]: /images/20221022/eee834c7cb034f7cba7d0017806fadfc.png
[f562fc6be566e3e1b23745e6bbb29cd7.png]: /images/20221022/9d3301c4fd3f4a49acab389ef95c6de0.png
[011fac87576c55420779e0323da78d42.png]: /images/20221022/0d1bc5c73e0d4bd6a3ff68d7d40ce03c.png
[07b0c7b26bd617d843edf722463b4124.png]: /images/20221022/428b4d337641441bbd300e870dcea869.png
[MySQL_25]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd55694bca22e05d2d6bf09ea577a9c00a3842320a542d888bcffa2cf527e92f45bd92b6340f&idx=1&mid=2247500192&scene=21&sn=ea1967dba7d155cb786a87112e14f701#wechat_redirect
[12]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd55685aca22e14cbf1a0292b45e1cb05d4e89008b0f21facb058d26d4ba58591ed8328a5177&idx=1&mid=2247499953&scene=21&sn=4eadc79edac61cb349c1496b57dab73d#wechat_redirect
[12 1]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd55684dca22e15b7c0b801142f5a038b4c6ed86a21fe7e3c9c11ae8984569eae3ad811e67fa&idx=1&mid=2247499942&scene=21&sn=7fe98b1860204dcde8eb087dacc7a7a6#wechat_redirect
[JVM_18]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd5568e5ca22e1f3ee3819e62fa72e040e66cf57e76433a10da24f66f1482e0380f04a20d6ff&idx=1&mid=2247499790&scene=21&sn=5b1eae8be6ef173b8be416e4a3aa3ceb#wechat_redirect
[HashMap_31_5]: http://mp.weixin.qq.com/s?__biz=MzU4MDM3MDgyMA%3D%3D&chksm=fd556928ca22e03e574ca10c7b8afe2bab0d44d1f01490ec83e7d14e111dedd7bc617b8742f2&idx=1&mid=2247500227&scene=21&sn=88ceef5f2a09efe2832cdb68578720b1#wechat_redirect
[Redis_43]: http://mp.weixin.qq.com/s?__biz=MzI1MTYxNTE0Ng%3D%3D&chksm=e9f10751de868e47db8f327763a82dda3c0ef20b281320177b4a35a1b3b5039dc2cfa3c086ab&idx=1&mid=2247484820&scene=21&sn=de076ddd3b6a72d34fc7ae183e9cc194#wechat_redirect