ConcurrentHashMap

ConcurrentHashMap是什么

Concurrent翻译过来是并发的意思，字面理解它的作用是处理并发情况的 HashMap，在介绍它之前先回顾下之前的知识。通过前面两篇学习，我们知道多线程并发下 HashMap 是不安全的(如死循环)，更普遍的是多线程并发下，由于堆内存对于各个线程是共享的，而 HashMap 的 put 方法不是原子操作，假设Thread1先 put 值，然后 sleep 2秒(也可以是系统时间片切换失去执行权)，在这2秒内值被Thread2改了，Thread1“醒来”再 get 的时候发现已经不是原来的值了，这就容易出问题。

那么如何避免这种多线程“奥迪变奥拓”的情况呢？常规思路就是给 HashMap 的 put 方法加锁(synchronized)，保证同一个时刻只允许一个线程拥有对 hashmap 有写的操作权限即可。然而假如线程1中操作耗时，占着茅坑半天不出来，其他需要操作该 hashmap 的线程就需要在门口排队半天，严重影响用户体验(HashTable 就是这么干的)。举个生活中的例子，很多银行除了存取钱，还支持存取贵重物品，贵重物品都放在保险箱里，把 HashMap 和 HashTable 比作银行，结构：

把线程比作人，对应的情况如下：

• HashMap牌银行：我们的服务宗旨是不用排队，同一时间多人都有机会修改保险柜里的东西，你以为你存的是美元？取出来的其实是日元，破产就在一瞬间，刺不刺激。
• HashTable牌银行：我们的服务宗旨是要排队，同一时间只有一个人有机会修改保险柜里的东西，其余的人只能看不能动手改，保你存的是美元取得还是美元。什么？你说如果那人在里面睡着了不出来怎么办？不要着急，来，坐下来打会麻将等他出来。

多线程下用 HashMap 不确定性太高，有破产的风险，不能选；用 HashTable 不会破产，但是用户体验不太好，那么怎样才能做到多人存取既不影响他人存值，又不用排队呢？有人提议搞个「银行者联盟」，多开几个像HashTable 这种「带锁」的银行就好了，有多少人办理业务，就开多少个银行，一对一服务，这个区都是大老板，开银行的成本都是小钱，于是「银行者联盟」成立了。

接下来的情况是这样的：比如盖伦和亚索一起去银行存他们的大宝剑，这个「银行者联盟」一顿操作，然后对盖伦说，1号银行现在没人，你可以去那存，不用排队，然后盖伦就去1号银行存他的大宝剑，1号银行把盖伦接进门，马上拉闸，一顿操作，然后把盖伦的大宝剑放在第x行第x个保险箱，等盖伦办妥离开后，再开闸；同样「银行者联盟」对亚索说，2号银行现在没人，你可以去那存，不用排队，然后亚索去2号银行存他的大宝剑，2号银行把亚索接进门，马上拉闸，一顿操作把亚索的大宝剑放在第x行第x号保险箱，等亚索离开后再开闸，此时不管盖伦和亚索在各自银行里面待多久都不会影响到彼此，不用担心自己的大宝剑被人偷换了。这就是ConcurrentHashMap的设计思路，用一个图来理解

从上图可以看出，此时锁的是对应的单个银行，而不是整个「银行者联盟」。分析下这种设计的特点：

• 多个银行组成的「银行者联盟」
• 当有人来办理业务时，「银行者联盟」需要确定这个人去哪个银行
• 当此人去到指定银行办理业务后，该银行上锁，其他人不能同时执行修改操作，直到此人离开后解锁

由这几点基本思想可以引发一些思考，比如：

1.成立「银行者联盟」时初始银行数是多少？怎么设计合理？

上面这张图没有给出是否需要排队的结论，这是因为需要结合实际情况分析，比如初始化有16个银行，只有两个人来办理业务，那自然不需要排队；如果现在16个银行都有人在办理业务，这时候来了第17个人，那么他还是需要排队的。由于「银行者联盟」事先无法得知会有多少人来办理业务，所以在它创立的时候需要制定一个「标准」，即初始银行数量，人多的情况「银行者联盟」应该多开几家银行，避免别人排队；人少的情况应该少开，避免浪费钱(什么，你说不差钱？那也不行)

2.当有人来办理业务的时候，「银行者联盟」怎么确定此人去哪个银行？

正常情况下，如果所有银行都是未上锁状态，那么有人来办理业务去哪都不用排队，当其中有些银行已经上锁，那么后续「银行者联盟」给人推荐的时候就不能把客户往上锁的银行引了，否则分分钟给人锤成麻瓜。因此「银行者联盟」需要时刻保持清醒的头脑，对自己的银行空闲情况了如指掌，每次给用户推荐都应该是最好的选择。

3.「银行者联盟」怎么保证同一时间不会有两个人在同一个银行拥有存权限？

通过对指定银行加锁/解锁的方式实现。