JDK 源码复习 concurrent 包 concurrentHashMap 02

1. 原理解析

利用 ==CAS + synchronized== 来保证并发更新的安全
底层使用==数组+链表+红黑树==来实现

1.1. 重要成员变量
table：默认为null，初始化发生在第一次插入操作，默认大小为16的数组，用来存储Node节点数据，扩容时大小总是2的幂次方。
nextTable：默认为null，扩容时新生成的数组，其大小为原数组的两倍。
sizeCtl ：默认为0，用来控制table的初始化和扩容操作，具体应用在后续会体现出来。
-1 代表table正在初始化
-N 表示有N-1个线程正在进行扩容操作
其余情况：
1、如果table未初始化，表示table需要初始化的大小。
2、如果table初始化完成，表示table的容量，默认是table大小的0.75倍，居然用这个公式算0.75（n - (n >>> 2)）。
Node：保存key，value及key的hash值的数据结构。
其中value和next都用volatile修饰，保证并发的可见性。

节点已经存在，修改链表节点的值

节点不存在，添加到链表末尾

链表节点超过了8，链表转为红黑树；统计节点个数，检查是否需要resize

 

1.2. 实例初始化
实例化ConcurrentHashMap时倘若声明了table的容量，在初始化时会根据参数调整table大小，==确保table的大小总是2的幂次方==。默认的table大小为16.

table的初始化操作回延缓到第一put操作再进行，并且初始化只会执行一次。

1.3. put操作
1.3.1 put过程描述
假设table已经初始化完成，put操作采用==CAS+synchronized==实现并发插入或更新操作：
- 当前bucket为空时，使用CAS操作，将Node放入对应的bucket中。
- 出现hash冲突，则采用synchronized关键字。倘若当前hash对应的节点是链表的头节点，遍历链表，若找到对应的node节点，则修改node节点的val，否则在链表末尾添加node节点；倘若当前节点是红黑树的根节点，在树结构上遍历元素，更新或增加节点。
- 倘若当前map正在扩容f.hash == MOVED，则先协助扩容，再更新值

如果所有的节点都已经完成复制工作 就把nextTable赋值给table 清空临时对象nextTable

扩容阈值设置为原来容量的1.5倍 依然相当于现在容量的0.75倍

利用CAS方法更新这个扩容阈值，在这里面sizectl值减一，说明新加入一个线程参与到扩容操作

//如果遍历到的节点为空 则放入ForwardingNode指针

//如果遍历到ForwardingNode节点 说明这个点已经被处理过了 直接跳过 这里是控制并发扩容的核心

//  resize后的元素要么在原地，要么移动n位（n为原capacity）

以下的部分在完成的工作是构造两个链表 一个是原链表 另一个是原链表的反序排列

在nextTable的i位置上插入一个链表

在nextTable的i+n的位置上插入另一个链表

//设置advance为true 返回到上面的while循环中 就可以执行i--操作

//对TreeBin对象进行处理 与上面的过程类似

//构造正序和反序两个链表

 

（1）如果lo链表的元素个数小于等于UNTREEIFY_THRESHOLD，默认为6，则通过untreeify方法把树节点链表转化成普通节点链表；

（2）否则判断hi链表中的元素个数是否等于0：如果等于0，表示lo链表中包含了所有原始节点，则设置原始红黑树给ln，否则根据lo链表重新构造红黑树。

1.4.2 treeify

   //构造了一个TreeBin对象 把所有Node节点包装成TreeNode放进去

   //这里只是利用了TreeNode封装 而没有利用TreeNode的next域和parent域

 

1.5. get操作

读取操作，不需要同步控制，比较简单
1. 空tab，直接返回null
2. 计算hash值，找到相应的bucket位置，为node节点直接返回，否则返回null

1.6. 统计size
ConcurrentHashMap的元素个数等于baseCounter和数组里每个CounterCell的值之和，这样做的原因是，当多个线程同时执行CAS修改baseCount值，失败的线程会将值放到CounterCell中。所以统计元素个数时，要把baseCount和counterCells数组都考虑。

1.7 删除元素

1.7.1 清空map：clear

清空tab的过程：
遍历tab中每一个bucket，
1. 当前bucket正在扩容，先协助扩容
2. 给当前bucket上锁，删除元素
3. 更新map的size

/检测到其他线程正对其扩容 //则协助其扩容，然后重置计数器，重新挨个删除元素，避免删除了元素，其他线程又新增元素

putVal() 方法

 

4. ConcurrentHashMap能完全替代HashTable吗？
hash table虽然性能上不如ConcurrentHashMap，但并不能完全被取代，两者的迭代器的一致性不同的，hash table的迭代器是强一致性的，而concurrenthashmap是弱一致的。 ConcurrentHashMap的get，clear，iterator 都是弱一致性的。
下面是大白话的解释：
- Hashtable的任何操作都会把整个表锁住，是阻塞的。好处是总能获取最实时的更新，比如说线程A调用putAll写入大量数据，期间线程B调用get，线程B就会被阻塞，直到线程A完成putAll，因此线程B肯定能获取到线程A写入的完整数据。坏处是所有调用都要排队，效率较低。
- ConcurrentHashMap 是设计为非阻塞的。在更新时会局部锁住某部分数据，但不会把整个表都锁住。同步读取操作则是完全非阻塞的。好处是在保证合理的同步前提下，效率很高。坏处 是严格来说读取操作不能保证反映最近的更新。例如线程A调用putAll写入大量数据，期间线程B调用get，则只能get到目前为止已经顺利插入的部分 数据。

选择哪一个，是在性能与数据一致性之间权衡。ConcurrentHashMap适用于追求性能的场景，大多数线程都只做insert/delete操作，对读取数据的一致性要求较低。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

java8的ConcurrentHashMap为何放弃分段锁

如果某个段比较大，并且竞争这个分段锁概率很小，会导致分段锁性能下降。

 

jdk1.7分段锁的实现

和hashmap一样，在jdk1.7中ConcurrentHashMap的底层数据结构是数组加链表。和hashmap不同的是ConcurrentHashMap中存放的数据是一段段的，即由多个Segment(段)组成的。每个Segment中都有着类似于数组加链表的结构。默认16个分段

jdk1.8的map实现

和hashmap一样,jdk 1.8中ConcurrentHashmap采用的底层数据结构为数组+链表+红黑树的形式。数组可以扩容，链表可以转化为红黑树。

什么时候扩容？

1. 当前容量超过阈值
2. 当链表中元素个数超过默认设定（8个），当数组的大小还未超过64的时候，此时进行数组的扩容，如果超过则将链表转化成红黑树

什么时候链表转化为红黑树？

当数组大小已经超过64并且链表中的元素个数超过默认设定（8个）时，将链表转化为红黑树

把数组中的每个元素看成一个桶。可以看到大部分都是CAS操作，加锁的部分是对桶的头节点进行加锁，锁粒度很小。

为什么不用ReentrantLock而用synchronized ?

• 减少内存开销:如果使用ReentrantLock则需要节点继承AQS来获得同步支持，增加内存开销，而1.8中只有头节点需要进行同步。
• 内部优化:synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

4. ConcurrentHashMap能完全替代HashTable吗？

HashTable虽然性能上不如ConcurrentHashMap，但并不能完全被取代，两者的迭代器的一致性不同的，HashTable的迭代器是强一致性的，而ConcurrentHashMap是弱一致的。 ConcurrentHashMap的get，clear，iterator 都是弱一致性的。 Doug Lea 也将这个判断留给用户自己决定是否使用ConcurrentHashMap。

那么什么是强一致性和弱一致性呢？

get方法是弱一致的，是什么含义？可能你期望往ConcurrentHashMap底层数据结构中加入一个元素后，立马能对get可见，但ConcurrentHashMap并不能如你所愿。换句话说，put操作将一个元素加入到底层数据结构后，get可能在某段时间内还看不到这个元素，若不考虑内存模型，单从代码逻辑上来看，却是应该可以看得到的。

下面将结合代码和java内存模型相关内容来分析下put/get方法。put方法我们只需关注Segment#put，get方法只需关注Segment#get，在继续之前，先要说明一下Segment里有两个volatile变量：count和table；HashEntry里有一个volatile变量：value。

可以注意到，同一个Segment实例中的put操作是加了锁的，而对应的get却没有。根据hb关系中的线程间Action类别，可以从上图中找出这些Action，主要是volatile读写和加解锁，也就是图中画了横线的那些。

put操作可以分为两种情况，一是key已经存在，修改对应的value；二是key不存在，将一个新的Entry加入底层数据结构。

key已经存在的情况比较简单，即if (e != null)部分，前面已经说过HashEntry的value是个volatile变量，当线程1给value赋值后，会立马对执行get的线程2可见，而不用等到put方法结束。

key不存在的情况稍微复杂一些，新加一个Entry的逻辑在else中。那么将new HashEntry赋值给tab[index]是否能立刻对执行get的线程可见呢？我们只需分析写tab[index]与读取tab[index]之间是否有hb关系即可。

也就是说，如果某个Segment实例中的put将一个Entry加入到了table中，在未执行count赋值操作之前有另一个线程执行了同一个Segment实例中的get，来获取这个刚加入的Entry中的value，那么是有可能取不到的！

 

 

采用Segment数组结构和HashEntry数组结构组成，Segment数组的大小就是ConcurrentHashMap的并发度。Segment继承自ReentrantLock，所以他本身就是一个锁。Segment数组一旦初始化后就不会再进行扩容，这也是jdk1.8去掉他的原因。Segment里面又包含了一个table数组，这个数组是可以扩容的。

如图我们在定位数据的时候需要对key的hash值进行两次寻址操作，第一次找到在Segment数组的位置，第二次找到在table数组中的位置。

 

JDK1.7 

Segment.put() 方法

Segment.rehash() 扩容方法

get() 方法

   我们可以看到get方法是没有加锁的，因为HashEntry的value和next属性是volatile的，volatile直接保证了可见性，所以读的时候可以不加锁。Java中Unsafe类可以参考这篇博客。

size的核心思想是先进性两次不加锁统计，如果两次的值一样则直接返回，否则第三个统计的时候会将所有segment全部锁定，再进行size统计，所以size()尽量少用。因为这是在并发情况下，size其他线程也会改变size大小，所以size()的返回值只能表示当前线程、当时的一个状态，可以算其实是一个预估值。

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

红黑树相关

红黑树
先看红黑树的基本概念：红黑树是一课特殊的平衡二叉树，主要用它存储有序的数据，提供高效的数据检索，时间复杂度为O(lgn)。红黑树每个节点都有一个标识位表示颜色，红色或黑色，具备五种特性：

每个节点非红即黑
根节点为黑色
每个叶子节点为黑色。叶子节点为NIL节点，即空节点
如果一个节点为红色，那么它的子节点一定是黑色
从一个节点到该节点的子孙节点的所有路径包含相同个数的黑色节点

2.2 内侧插入

以N是P的左子节点，P是G的右子节点情况为例。内侧插入的情况稍微复杂些，经过一次旋转、着色是无法调整为红黑树的，处理方法如下：先进行一次右旋，再进行一次左旋，然后重新着色，即可完成调整。注意这里两次右旋都是以新增节点N为支点不是P。这里将N节点的两个NIL节点命名为X、L。如下：
 

至于左内侧则处理逻辑如下：先进行右旋，然后左旋，最后着色。

先判断当前Node的数组长度是否小于MIN_TREEIFY_CAPACITY（64），如果小于则调用tryPresize扩容处理以缓解单个链表元素过大的性能问题。否则则将Node节点的链表转换为TreeNode的节点链表，构建完成之后调用setTabAt()构建红黑树。TreeNode继承Node