ConcurrentHashMap一点理解(1.7 @Deprecate)

有人的地方就有江湖,江湖中都是套路.之前面试过一个传统企业叫杭州三汇，从面试官的口中得知是做公安项目的，公司本身做CTI语音网关.面试过程就是一个和我差不多年纪的面试官完了上来问了一些简单的问题，基本上都不需要思索就对答如流，半个小时了依旧没有把我面倒我还举一反三了.HR说我不靠谱，我质疑了一下是不是我技术问题，后来才知道面试官心虚了….人家还妄图对我有offer的企业进行一番嘲讽，但是后来人定胜天技术战胜一切，人家最后也承认说怕去了之后人留不住，说我的技术栈比较适合互联网企业.mmp，全是套路…

抱怨完毕来看看ConcurrentHashMap,这个东西是1.5以后出现的,在java.util.concurrent包下的.看ConcurrentHashMap的源码之前必须先了解HashMap,HashTable,Synchronized,ReentrantLock等技术点.

HashMap的数据结构是Node[]数组 + 链表结构.对应的有HashTable，一定程度上等同于HashMap.HashMap和HashTable都实现了Map接口.HashMap因为不是同步的,所以会有线程安全问题,而HashTable是同步的所以线程安全.当然的,在单线程操作下,HashMap的效率比HashTable要高.
HashTable是通过Synchroinzed来保证线程安全,副作用是一次只能有一个线程去修改HashTable,必须先获得其同步锁才能进行修改,其他线程必须等待锁被释放之后才能获得执行权去修改HashTable.HashMap的迭代器是fail-safe,而HashTable是Enumerator.

1.5以后出现的ConcurrentHashMap,解决了HashTabe安全但效率低,HashMap效率高但不能保证线程安全的这样的痛点.

再提一下ReentrantLock,这个类实现了Lock接口是1.5以后出现的一种锁,相比较Synchronized这种同步锁而言ReentrantLock更加灵活.Synchronized是互斥的,而ReentrantLock作用类似于Synchronized,但是不用和Synchronized一样在获取锁的时候必须等待,可以设置轮询,定时,中断,在多个锁的情况下可以避免死锁,只是释放锁的操作必须注意,最好try catch finally并且在finally中释放锁,否则在代码出问题的时候锁没办法释放了.ConcurrentHashMap中的Hash区间使用的锁就是ReentrantLock.(注意:1.8以后ConcurrentHashMap出现了较大的变化 ，我会重新写一篇ConcurrentHashMap的文章来阐述)

ConcurrentHashMap的数据结构如图:

一个Segment[]数组上挂了一堆HashEntry,而HashEntry的数据结构也是K->V结构,HashEntry中有entries[]数组,数组的index对应的是链表结构.是不是有一种HashMap的既视感.

先搞清Segment[]，Segment是ConcurrentHashMap中维护的一个静态内部类,这是源码中的内容.

Segment继承了ReentrantLock,里面有维护一个常量loadFactor,并且在构造中进行了赋值.
因为Segment继承ReentrantLock,所以Segment本身也可以是一种锁.在ConcurrentHashMap中每一个Segment中对应的数据需要同步操作的时候,都使用自身的锁来实现.这样在高并发下的性能就能够保证.

再看看ConcurrentHashMap的使用方法的源码.

如图是ConcurrentHashMap的get(Object key)方法