ConcurrentHashMap 1.7与1.8的区别
1、数据结构不同
1.7 ReentrantLock+Segment+HashEntry 需要两次Hash
1.8 Synchronized+CAS+HashEntry+红黑树, 只需要一次hash
上图是1.7的数据结构
关于1.7的数据结构是通过Segment数据 + HashEntry数组 + 链表的方式,其中Segment是Reentrant的子类,所以Segment数组中的每个元素都是一个锁,在得到具体的Segment数组下标后,在通过hash从HashEntry里面得到具体的元素位置,而且这个位置可能是一个链表,主要是因为hash冲突。下面是代码
ConcurrentHashMap{
//1、先是Segment数组,第一次hash找Segment
Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
static final class Segment<K,V> extends ReentrantLock{
//2、接着是HashEntry数组,第二次hash找HashEntry
transient volatile HashEntry<K,V>[] table;
}
static final class HashEntry<K,V> {
final int hash;
final K key;
volatile V value;
volatile HashEntry<K,V> next; Hash冲突时,链表。
}
}
Jdk1.8数据结构
public class ConcurrentHashMap{
//一次Hash
transient volatile Node<K,V>[] table;
static class Node<K,V> {
final int hash;
final K key;
volatile V val;
volatile Node<K,V> next;//Hash冲突时,链表解决
}
}
2、锁结构不同
1.7是Reentrant
1.8是Synchronized和CAS
3、put的流程不同
JDK1.7中,ConcurrentHashMap要进行两次定位,先对Segment进行定位,再对其内部的数组下标进行定位。
定位之后会采用自旋锁+锁膨胀的机制进行加锁。 也就是【自旋】【获取锁】,当自旋次数超过64时,会发生膨胀直接陷入【阻塞状态】,等待唤醒。
并且在整个put操作期间都持有锁。
JDK1.8中只需要一次定位,并且采用CAS+synchronized的机制。如果对应下标处没有结点,说明没有发生哈希冲突,此时直接通过【CAS进行】插入,
若成功,直接返回。如果有Hash冲突,则使用【synchronized】进行加锁插入。
4、size的计算方式不同
1.7采用类似于乐观锁的机制,先是不加锁直接进行统计,最多执行三次,如果前后两次计算的结果一样,则直接返回。若超过了三次,
则对每一个Segment进行加锁后再统计。
1.8 会维护一个baseCount属性用来记录结点数量,每次进行put操作之后都会CAS自增baseCount,使用的使用base+cell[]计算,有点类似于LongAdder。
5、扩容的区别
1.7 只扩容当前Segment中的【HashEntry数组】即可。也就ConcurrentHashMap中的【Segment数组】在初始化的时候就【确定】了,
后面扩容不会改变这个长度。相比较HashMap的resize操作,ConcurrentHashMap的rehash原理类似。但是对其做了一定优化,
避免让所有节点进行计算操作。这个和JDK1.8的计算【Hash下标】一样。
1,8 扩容
ConcurrentHashMap还【正在扩容】,说明整个concurrenHashMap正在扩容。那么进入helpTransfer方法,【协助进行扩容】,直到扩容完成。
ConcurrentHashMap如果当前需要操作的节点还不是ForwardingNode即还没有【完成扩容】操作,那么会直接使用源tab,进行操作。
对于写操作,在扩容期间,除了锁住【头节点】的槽,和【已经扩容完成】的节点,其他节点依然正常读写。不会因为访问这些节点进入协助扩容!,
可见ConcurrentHashMap对锁粒度的控制十分细。
协助扩容是指什么? 其实就是多线程扩容,多个线程一同参与,每个线程完成一部分元素的复制操作。
跳转地址:跳转