本篇文章站在多线程并发安全角度，带你了解多线程并发使用HashMap将会引发的问题，深入学习ConcurrentHashMap，带你彻底掌握这些核心技术。
全文摘要：
HashMap核心技术ConcurrentHashMap核心技术分段锁实战应用HashMap
HashMap是我们经常会用到的集合类，JDK1.7之前底层使用了数组加链表的组合结构，如下图所示：
新添加的元素通过取模的方式，定位Table数组位置，然后将元素加入链表头部，这样下次提取时就可以快速被访问到。
访问数据时，也是通过取模的方式，定位数组中的位置，然后再遍历链表，依次比较，获取相应的元素。
如果HasMap中元素过多时，可能导致某个位置上链表很长。原本O(1)查找性能，可能就退化成O(N),严重降低查找效率。
为了避免这种情况，当HasMap元素数量满足以下条件时，将会自动扩容,重新分配元素。
HasMap将会把容量扩充为原来的两倍，然后将原数组元素迁移至新数组。
旧数组元素迁移到新数组时，依旧采用『头插入法』，这样将会导致新链表元素的逆序排序。
多线程并发扩容的情况下，链表可能形成死链（环形链表）。一旦有任何查找元素的动作，线程将会陷入死循环,从而引发CPU使用率飙升。
JDK1.8改进方案
JDK1.8HashMap底层结构进行彻底重构，使用数组加链表/红黑树方式这种组合结构。
新元素依旧通过取模方式获取Table数组位置，然后再将元素加入链表尾部。一旦链表元素数量超过8之后，自动转为红黑树，进一步提高了查找效率。
面试题：为什么这里使用红黑树？而不是其他二叉树呢？
由于JDK1.8链表采用『尾插入』法，从而避免并发扩容情况下链表形成死链的可能。
那么HashMap在JDK1.8版本就是并发安全的吗？其实并没有，多线程并发的情况，HashMap可能导致丢失数据。
下面是一段JDK1.8测试代码：
在我的电脑上输出如下，数据发生了丢失：
从源码出发，并发过程数据丢失的原因有以下几点：
并发赋值时被覆盖
并发的情况下，一个线程的赋值可能被另一个线程覆盖，这就导致对象的丢失。
size计算问题
每次元素增加完成之后，size将会加1。这里采用++i方法，天然的并发不安全。
对象丢失的问题原因可能还有很多，这里只是列举两个比较的明显的问题。当然JDK1.7中也是存在数据丢失的问题，问题原因也比较相似。
一旦发生死链的问题，机器CPU飙升，通过系统监控，我们可以很容易发现。
但是数据丢失的问题就不容易被发现。因为数据丢失环节往往非常长，往往需要系统运行一段时间才可能出现，而且这种情况下又不会形成脏数据。只有出现一些诡异的情况，我们才可能去排查，而且这种问题排查起来也比较困难。
SynchronizedMap
对于并发的情况，我们可以使用JDK提供SynchronizedMap保证安全。
SynchronizedMap是一个内部类，只能通过以下方式创建实例。
Mapm=Collections.synchronizedMap(newHashMap(...));
SynchronizedMap源码如下:
每个方法内将会使用synchronized关键字加锁，从而保证并发安全。
由于多线程共享同一把锁，导致同一时间只允许一个线程读写操作，其他线程必须等待，极大降低的性能。
并且大多数业务场景都是读多写少，多线程读操作本身并不冲突，SynchronizedMap极大的限制读的性能。所以多线程并发场景我们很少使用SynchronizedMap。
ConcurrentHashMap
既然多线程共享一把锁，导致性能下降。那么设想一下我们是不是多搞几把锁，分流线程，减少锁冲突，提高并发度。
ConcurrentHashMap正是使用这种方法，不但保证并发过程数据安全，又保证一定的效率。
JDK1.7
JDK1.7ConcurrentHashMap数据结构如下所示:
Segament是一个ConcurrentHashMap内部类，底层结构与HashMap一致。另外Segament继承自ReentrantLock，类图如下:
当新元素加入ConcurrentHashMap时，首先根据keyhash值找到相应的Segament。接着直接对Segament上锁，若获取成功，后续操作步骤如同HashMap。
由于锁的存在，Segament内部操作都是并发安全，同时由于其他Segament未被占用，因此可以支持concurrencyLevel个线程安全的并发读写。
size统计问题
虽然ConcurrentHashMap引入分段锁解决多线程并发的问题，但是同时引入新的复杂度，导致计算ConcurrentHashMap元素数量将会变得复杂。
由于ConcurrentHashMap元素实际分布在Segament中，为了统计实际数量，只能遍历Segament数组求和。
为了数据的准确性，这个过程过我们需要锁住所有的Segament，计算结束之后，再依次解锁。不过这样做，将会导致写操作被阻塞，一定程度降低ConcurrentHashMap性能。
所以这里对ConcurrentHashMap#size统计方法进行一定的优化。
Segment每次被修改（写入，删除）,都会对modCount（更新次数）加1。只要相邻两次计算获取所有的SegmentmodCount总和一致，则代表两次计算过程并无写入或删除，可以直接返回统计数量。
如果三次计算结果都不一致，那没办法只能对所有Segment加锁，重新计算结果。
这里需要注意的是，这里求得size数量不能做到%准确。这是因为最后依次对Segment解锁后，可能会有其他线程进入写入操作。这样就导致返回时的数量与实际数不一致。
不过这也能被接受，总不能因为为了统计元素停止所有元素的写入操作。
性能问题
想象一种极端情况的，所有写入都落在同一个Segment中，这就导致ConcurrentHashMap退化成SynchronizedMap，共同抢一把锁。
JDK1.8改进方案
JDK1.8之后，ConcurrentHashMap取消了分段锁的设计，进一步减锁冲突的发生。另外也引入红黑树的结构，进一步提高查找效率。
数据结构如下所示：
Table数组的中每一个Node我们都可以看做一把锁，这就避免了Segament退化问题。
另外一旦ConcurrentHashMap扩容，Table数组元素变多，锁的数量也会变多，并发度也会提高。
写入元素源码比较复杂，这里可以参考下面流程图。
总的来说，JDK1.8使用CAS方法加synchronized方式，保证并发安全。
size方法优化
JDK1.8ConcurrentHashMap#size统计方法还是比较简单的：
这个方法我们需要知道两个重要变量：
baseCountCounterCell[]counterCellsbaseCount记录元素数量的，每次元素元素变更之后，将会使用CAS方式更新该值。如果多个线程并发增加新元素，baseCount更新冲突，将会启用CounterCell，通过使用CAS方式将总数更新到counterCells数组对应的位置，减少竞争。
如果CAS更新counterCells数组某个位置出现多次失败，这表明多个线程在使用这个位置。此时将会通过扩容counterCells方式，再次减少冲突。
通过上面的努力，统计元素总数就变得非常简单，只要计算baseCount与counterCells总和，整个过程都不需要加锁。
仔细回味一下，counterCells也是通过类似分段锁思想，减少多线程竞争。
分段锁实战应用
ConcurrentHashMap通过使用分段锁的设计方式，降低锁的粒度，提高并发度。我们可以借鉴这种设计，解决某些热点数据更新问题。
举个例子，假如现在我们有一个支付系统，用户每次支付成功，商家的账户余额就会相应的增加。
当大促的时候，非常多用户同时支付，同一个商家账户余额会被并发更新。
数据库层面为了保证数据安全，每次更新时将会使用行锁。同时并发更新的情况，只有一个线程才能获取锁，更新数据，其他线程只能等待锁释放。这就很有可能导致其他线程余额更新操作耗时过长，甚至事务超时，余额更新失败的。
这就是一个典型的热点数据更新问题。
这个问题实际原因是因为多线程并发抢夺行锁导致，那如果有多把行锁，是不是就可以降低锁冲突了那？
没错，这里我们借鉴ConcurrentHashMap分段锁的设计，在商家的账户的下创建多个影子账户。
然后每次更新余额，随机选择某个影子账户进行相应的更新。
理论上影子账户可以创建无数个，这就代表我们可以无限提高并发的能力。
架构设计中引入新的方案，就代表会引入新的复杂度，我们一定要这些问题考虑清楚，综合权衡设计。
引入影子账户虽然解决热点数据的问题，但是商户总余额统计就变得很麻烦，我们必须统计所有子账户的余额。
另外实际的业务场景，商家余额不只是会增加，还有可能的进行相应的扣减。这就有可能产生商户总余额是足够的，但是选中的影子账户的余额却不足。
这怎么办？这留给大家思考了。不知道各位读者有没有碰到这种类似的问题，欢迎留言讨论。
大家感兴趣的话，后面的文章我们可以详细聊聊热点账户的解决方案。
总结
HashMap在多线程并发的过程中存在死链与丢失数据的可能，不适合用于多线程并发使用的场景的,我们可以在方法的局部变量中使用。
SynchronizedMap虽然线程安全，但是由于锁粒度太大，导致性能太低，所以也不太适合在多线程使用。
ConcurrentHashMap由于使用多把锁，充分降低多线程并发竞争的概率，提高了并发度，非常适合在多线程中使用。
最后小黑哥再提一点，不要一提到多线程环境，就直接使用ConcurrentHashMap。如果仅仅使用Map当做全局变量，而这个变量初始加载之后，从此数据不再变动的场景下。
建议使用不变集合类Collections#unmodifiableMap,或者使用Guava的ImmutableMap。不变集合的好处在于，可以有效防止其他线程偷偷修改，从而引发一些业务问题。
ConcurrentHashMap分段锁的经典思想，我们可以应用在热点更新的场景，提高更新效率。
不过一定要记得，当我们引入新方案解决问题时，必定会引入新的复杂度，导致其他问题。这个过程一定要先将这些问题想清楚，然后这中间做一定权衡。
最后说一句（求