使用ConcurrentHashMap一定线程安全？

前言

老王为何半夜惨叫？几行代码为何导致服务器爆炸？说好的线程安全为何还是出问题？让我们一起收看今天的《走进IT》

正文

CurrentHashMap出现背景

说到ConcurrentHashMap的出现背景，还得从HashMap说起。

老王是某公司的苦逼Java开发，在互联网行业中，业务总是迭代得非常快。体现在代码中的话，就是v1.0的模块是单线程执行的，这时候使用HashMap是一个不错的选择。然而到了v1.5的版本，为了性能考虑，老王觉得把这段代码改成多线程会更有效率，那么说改就改，然后就愉快的发布上线了。

直到某天晚上，突然收到线上警报，服务器CPU占用100%。这时候惊醒起来一顿排查（百度，谷歌），结果发现原来是HashMap 在并发的环境下进行rehash的时候会造成链表的闭环，因此在进行get()操作的时候导致了CPU占用100%。喔，原来HashMap不是线程安全的类，在当前的业务场景中会有问题。那么你这时候又想到了Hashtable，没错，这是个线程安全的类，那我先用这个类替换不就行了，一顿commit，push，部署上去了，观察了一段时间，完美~再也没出现过类似的问题了。

但是好日子过的并不长久，运营的同事又找上门了，老王啊，XX功能怎么慢了这么多啊？这时候老王就纳闷了，我没改代码啊？不就上次替换了一个Hashtable，难道这里会有效率的问题？然后又是一顿排查（百度、谷歌），我去，果不其然，原来它线程安全的原因是因为在方法上都加了synchronized，导致我们全部操作都串行化了，难怪这么慢。

经过了2次掉陷阱的经验，这次的老王已经是非常谨慎的去寻求更好的解决方案了,这时他找到ConcurrentHashMap，而且为了避免再次掉坑他也去提前了解了实现原理，原来这个类是使用了Segment分段锁，每一个Segment都有自己的锁，这样冲突的的范围就变小了，效率也能提高不少。经过调研发现确实不错，于是他就放心的把Hashtable给替换掉了，从此运营再也没来吐槽了，老王又过上了幸福的日子。

经过一段时间紧张的业务开发，此时的项目已经去到了v2.0，之前的ConcurrentHashMap相关的代码已经被改的面目全非，逻辑也复杂了很多，但项目还是按时顺利的上线了。在项目在运行了一段时间以后，居然再次出现线程安全的问题，其根源竟然是ConcurrentHashMap，老王叕陷入了沉思…

为何会出问题?

抛开复杂的例子，我们用一个多线程并发获取map中的值并加1，看看最后输出的数字如何

public class CHMDemo {
   
    public static void main(String[] args) throws InterruptedException {
   
        ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<String,Integer>(