ConcurrentHashMap

ConcurrentHashMap

JDK8中ConcurrentHashMap参考了JDK8 HashMap的实现，采用了数组+链表+红黑树的实现方式来设计，内部大量采用CAS操作

JDK8中彻底放弃了Segment转而采用的是Node，其设计思想也不再是JDK1.7中的分段锁思想。

Node：保存key，value及key的hash值的数据结构。其中value和next都用volatile修饰，保证并发的可见性。

<strong>class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    volatile V val;
    volatile Node<K,V> next;
    //... 省略部分代码
} </strong>
1234567

Java8 ConcurrentHashMap结构基本上和Java8的HashMap一样，不过保证线程安全性。

在JDK8中ConcurrentHashMap的结构，由于引入了红黑树，使得ConcurrentHashMap的实现非常复杂，我们都知道，红黑树是一种性能非常好的二叉查找树，其查找性能为O（logN），但是其实现过程也非常复杂，而且可读性也非常差，Doug Lea的思维能力确实不是一般人能比的，早期完全采用链表结构时Map的查找时间复杂度为O（N），JDK8中ConcurrentHashMap在链表的长度大于某个阈值的时候会将链表转换成红黑树进一步提高其查找性能。

以put方法理解多线程下ConcurrentHashMap怎么实现安全性的

V putVal(K key, V value, boolean onlyIfAbsent) {
if (key == null || value == null) throw new NullPointerException(); // 键或值为空，抛出异常
// 键的hash值经过计算获得hash值
int hash = spread(key.hashCode());
int binCount = 0; //binCount值用来判断是否达到红黑树转化的阈值
for (Node<K,V>[] tab = table;😉 { // 无限循环
Node<K,V> f;
int n, i, fh;
if (tab == null || (n = tab.length) == 0) // 表为空或者表的长度为0
// 初始化表
tab = initTable(); //对于table的大小，会根据sizeCtl的值进行设置，如果没有设置szieCtl的值，那么默认生成的table大小为16，否则，会根据sizeCtl的大小设置table大小。

//tabAt函数返回table数组中下标为i的结点，可以看到是通过Unsafe对象通过反射获取的，getObjectVolatile的第二项参数为下标为i的偏移地址。

​ else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // 表不为空并且表的长度大于0，并且该桶为空
​ if (casTabAt(tab, i, null,
​ new Node<K,V>(hash, key, value, null))) // 比较并且交换值，如tab的第i项为空则用新生成的node替换
​ break; // no lock when adding to empty bin
​ }
​ else if ((fh = f.hash) == MOVED) // 该结点的hash值为MOVED
​ // 进行结点的转移（在扩容的过程中）
​ tab = helpTransfer(tab, f);
​ else {
​ V oldVal = null;
​ synchronized (f) { // 加锁同步
​ if (tabAt(tab, i) == f) { // 找到table表下标为i的节点
​ if (fh >= 0) { // 该table表中该结点的hash值大于0
​ // binCount赋值为1
​ binCount = 1;
​ for (Node<K,V> e = f;; ++binCount) { // 无限循环
​ K ek;
​ if (e.hash == hash &&
​ ((ek = e.key) == key ||
​ (ek != null && key.equals(ek)))) { // 结点的hash值相等并且key也相等
​ // 保存该结点的val值
​ oldVal = e.val;
​ if (!onlyIfAbsent) // 进行判断
​ // 将指定的value保存至结点，即进行了结点值的更新
​ e.val = value;
​ break;
​ }
​ // 保存当前结点
​ Node<K,V> pred = e;
​ if ((e = e.next) == null) { // 当前结点的下一个结点为空，即为最后一个结点
​ // 新生一个结点并且赋值给next域
​ pred.next = new Node<K,V>(hash, key,
​ value, null);
​ // 退出循环
​ break;
​ }
​ }
​ }
​ else if (f instanceof TreeBin) { // 结点为红黑树结点类型
​ Node<K,V> p;
​ // binCount赋值为2
​ binCount = 2;
​ if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
​ value)) != null) { // 将hash、key、value放入红黑树
​ // 保存结点的val
​ oldVal = p.val;
​ if (!onlyIfAbsent) // 判断
​ // 赋值结点value值
​ p.val = value;
​ }
​ }
​ }
​ }
​ if (binCount != 0) { // binCount不为0
​ if (binCount >= TREEIFY_THRESHOLD) // 如果binCount大于等于转化为红黑树的阈值
​ // 进行转化
​ treeifyBin(tab, i);
​ if (oldVal != null) // 旧值不为空
​ // 返回旧值
​ return oldVal;
​ break;
​ }
​ }
​ }
​ // 增加binCount的数量
​ addCount(1L, binCount);
​ return null;

说明：put函数底层调用了putVal进行数据的插入，对于putVal函数的流程大体如下。

① 判断存储的key、value是否为空，若为空，则抛出异常，否则，进入步骤②

② 计算key的hash值，随后进入无限循环，该无限循环可以确保成功插入数据，若table表为空或者长度为0，则初始化table表，否则，进入步骤③

③ 根据key的hash值取出table表中的结点元素，若取出的结点为空(也就是不存在hash冲突的情况)，则使用CAS将key、value、hash值生成的结点放入桶中。否则，进入步骤④

④ 若该结点的的hash值为MOVED，则对该桶中的结点进行转移，否则，进入步骤⑤

⑤ 对桶中的第一个结点（即table表中的结点）进行加锁，对该桶进行遍历，桶中的结点的hash值与key值与给定的hash值和key值相等，则根据标识选择是否进行更新操作（用给定的value值

替换该结点的value值），若遍历完桶仍没有找到hash值与key值和指定的hash值与key值相等的结点，则直接新生一个结点并赋值为之前最后一个结点的下一个结点。进入步骤⑥

⑥ 若binCount值达到红黑树转化的阈值，则将桶中的结构转化为红黑树存储，最后，增加binCount的值。

ConcurrentHashMap对于多线程put的实现其实就是对于node节点上锁，再使用CAS操作更新节点

总结

其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树。

1.数据结构：取消了Segment分段锁的数据结构，取而代之的是数组+链表+红黑树的结构。
2.保证线程安全机制：JDK1.7采用segment的分段锁机制实现线程安全，其中segment继承自ReentrantLock。JDK1.8采用CAS+Synchronized保证线程安全。
3.锁的粒度：原来是对需要进行数据操作的Segment加锁，现调整为对每个数组元素加锁（Node）。
4.链表转化为红黑树:定位结点的hash算法简化会带来弊端,Hash冲突加剧,因此在链表节点数量大于8时，会将链表转化为红黑树进行存储。
5.查询时间复杂度：从原来的遍历链表O(n)，变成遍历红黑树O(logN)。