面试官：请你谈谈ConcurrentHashMap

电玩女神 2022-11-12 11:59 220阅读 0赞

![268a46f60f8556572a4292507f133e47.gif][]

点击上方蓝字，关注我们

![c666f8b2da76f3a843068e3ea1828e57.gif][]

没啥深入实践的理论系同学，在使用并发工具时，总是认为把HashMap改为ConcurrentHashMap，就完美解决并发了呀。或者使用写时复制的CopyOnWriteArrayList，性能更佳呀！技术言论虽然自由，但面对魔鬼面试官时，我们更在乎的是这些真的正确吗？

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

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

![cfaa49f9b868f495f1cbb28cf4e73ae4.png][]

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

### 案例 ###

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

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

### bug 重现 ###

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

server.tomcat.max-threads=1

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

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

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

### 解决方案 ###

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

![77b4ef9ee02ac5bdb886e02ab692c2c0.png][]

ThreadLocal利用独占资源的解决线程安全问题，若就是要资源在线程间共享怎么办？就需要用到线程安全的容器。使用了线程安全的并发工具，并不代表解决了所有线程安全问题。

### 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是个线程安全的哈希表容器，但它仅保证提供的原子性读写操作线程安全。

### 案例 ###

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

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

![eebc2bc192bd66d46347087faf0180b8.png][]

*  访问接口

分析日志输出可得：

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

### bug 分析 ###

ConcurrentHashMap就像是一个大篮子，现在这个篮子里有900个桔子，我们期望把这个篮子装满1000个桔子，也就是再装100个桔子。有10个工人来干这件事儿，大家先后到岗后会计算还需要补多少个桔子进去，最后把桔子装入篮子。ConcurrentHashMap这篮子本身，可以确保多个工人在装东西进去时，不会相互影响干扰，但无法确保工人A看到还需要装100个桔子但是还未装时，工人B就看不到篮子中的桔子数量。你往这个篮子装100个桔子的操作不是原子性的，在别人看来可能会有一个瞬间篮子里有964个桔子，还需要补36个桔子。

ConcurrentHashMap对外提供能力的限制：

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

### 解决方案 ###

整段逻辑加锁：

![72943d191533a178796fe360961e46da.png][]

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

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

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

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

### 案例 ###

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

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

show me code:

![a983fc92ca4a092e023f22c72da08d92.png][]

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

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

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

![ecac2f73cccfc30271025cc3504dc224.png][]

*  ConcurrentHashMap的原子性方法computeIfAbsent做复合逻辑操作，判断K是否存在V，若不存在，则把Lambda运行后结果存入Map作为V，即新创建一个LongAdder对象，最后返回V 因为computeIfAbsent返回的V是LongAdder，是个线程安全的累加器，可直接调用其increment累加。这样在确保线程安全的情况下达到极致性能，且代码行数骤减。

### 性能测试 ###

*  使用StopWatch测试两段代码的性能，最后的断言判断Map中元素的个数及所有V的和是否符合预期来校验代码正确性
 *  性能测试结果：比使用锁性能提升至少5倍。

### 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进去）

## CopyOnWriteArrayList 之殇 ##

再比如一段简单的非 DB操作的业务逻辑，时间消耗却超出预期时间，在修改数据时操作本地缓存比回写DB慢许多。原来是有人使用了CopyOnWriteArrayList缓存大量数据，而该业务场景下数据变化又很频繁。CopyOnWriteArrayList虽然是一个线程安全版的ArrayList，但其每次修改数据时都会复制一份数据出来，所以只适用读多写少或无锁读场景。所以一旦使用CopyOnWriteArrayList，一定是因为场景适宜而非炫技。

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

*  测试并发写性能
 *  测试结果：高并发写，CopyOnWriteArray比同步ArrayList慢百倍
 *  测试并发读性能
 *  测试结果：高并发读（100万次get操作），CopyOnWriteArray比同步ArrayList快24倍

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

## 总结 ##

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

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

### Do !!! ###

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

[![6d0424e260e874ec5535207f64f1f6f2.png][]][6d0424e260e874ec5535207f64f1f6f2.png 1]

[ClickHouse在趣头条中的实战PPT][6d0424e260e874ec5535207f64f1f6f2.png 1]

[![da10e6664478208eeac3a0a72b2143e7.png][]][da10e6664478208eeac3a0a72b2143e7.png 1]

[面试官：请你讲讲Redis官方提供的高可用方案？][da10e6664478208eeac3a0a72b2143e7.png 1]

**回复**【**干货**】获取精选干货视频教程

**回复**【**加群**】加入疑难问题攻坚交流群

**回复**【**mat**】获取内存溢出问题分析详细文档教程

**回复**【**赚钱**】获取用java写一个能赚钱的微信机器人

**回复**【**副业**】获取程序员副业攻略一份

![fd7c08f579fc397cccccf3a1318ca476.png][]

![65245e2d5dfc3bc46b338e640f9a9f2e.png][]

点下在看，你最好看

[268a46f60f8556572a4292507f133e47.gif]: /images/20221022/26b8afa6d7ac4cdbb935d9fdf3c5a618.png
[c666f8b2da76f3a843068e3ea1828e57.gif]: /images/20221022/c749b1a774b9421c98120e8db3109d0a.png
[cfaa49f9b868f495f1cbb28cf4e73ae4.png]: /images/20221022/8e1c21ad90e047e09023b0e48d2b2fe7.png
[77b4ef9ee02ac5bdb886e02ab692c2c0.png]: /images/20221022/fb7d01c520d34704b37fa3ae6df94224.png
[eebc2bc192bd66d46347087faf0180b8.png]: /images/20221022/6eba1dc2b14b442b9060d80ccad08580.png
[72943d191533a178796fe360961e46da.png]: /images/20221022/c33d5b1b7a584b1498d99b1bfb8af59c.png
[a983fc92ca4a092e023f22c72da08d92.png]: /images/20221022/9601e35f146e4be7953743b128cff3b1.png
[ecac2f73cccfc30271025cc3504dc224.png]: /images/20221022/3626d3c771ac47f9a0534353fde5fd38.png
[6d0424e260e874ec5535207f64f1f6f2.png]: /images/20221022/d6ef982cc31d4564aca6585ffc97c2db.png
[6d0424e260e874ec5535207f64f1f6f2.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e549cb336c5f7fee805990de19d13d37d573467e1394795703835e539baa6768b2959733&idx=1&mid=2247487600&scene=21&sn=424808fc954f668ea625a3cc6adf606a#wechat_redirect
[da10e6664478208eeac3a0a72b2143e7.png]: /images/20221022/f1e849f0003c43e685126d13685c534f.png
[da10e6664478208eeac3a0a72b2143e7.png 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e55ccb336c4a2a7a14d70db0f87ed25a278cc96615209a4cf9422f71c76c5e4cf8e076ad&idx=1&mid=2247487589&scene=21&sn=45121211e8ea9eaa7166557ee6f761ac#wechat_redirect
[fd7c08f579fc397cccccf3a1318ca476.png]: /images/20221022/79003116c8604f379b5e1e3a443021d9.png
[65245e2d5dfc3bc46b338e640f9a9f2e.png]: /images/20221022/3caa2d1721b646c480075f1b21f74d2d.png