文章目录
一、:ConcurrentHashmap简介
HashMap是我们用得非常频繁的一个集合,但是由于它是非线程安全的,在多线程环境下,put操作是有可能产生死循环的,导致CPU利用率接近100%。为了解决该问题,JDK提供了Hashtable和Collections.synchronizedMap(hashMap)两种解决方案,但是这两种方案都是对读写加锁,独占式,一个线程在读时其他线程必须等待,吞吐量较低,性能较为低下。
基于以上原因,Doug Lea大神给我们提供了高性能的线程安全HashMap:ConcurrentHashMap。
老版本的ConcurrentHashMap利用锁分段的思想提高了并发度,在JDK1.8中,对ConcurrentHashMap进行了进一步升级,舍弃了segment,并且大量使用了synchronized以及CAS无锁操作,同时与Hashmap同步,底层采用了数组+链表+红黑树的数据形式。
二、:关键属性及类
①关键属性
// 装载Node的数组,作为ConcurrentHashMap的数据容器,采用懒加载的方式,直到第一次插入数据的时候才会进行初始化操作,数组的大小总是为2的幂次方
transient volatile Node<K,V>[] table;
// 扩容时使用,平时为null,只有在扩容的时候才为非null
private transient volatile Node<K,V>[] nextTable;
// 该属性用来控制table数组的大小,根据是否初始化和是否正在扩容有几种情况:
// 当值为0时,即数组长度为默认初始值
// 当值为负数时:如果为-1表示正在初始化,如果为-N则表示当前正有N-1个线程进行扩容操作
// 当值为正数时:如果当前数组为null的话表示table在初始化过程中,sizeCtl表示为需要新建数组的长度
// 若已经初始化了,表示当前数据容器(table数组)可用容量也可以理解成临界值(插入节点数超过了该临界值就需要扩容),具体指为数组的长度n乘以加载因子loadFactor;
private transient volatile int sizeCtl;
// Unsafe类,实现CAS操作
private static final sun.misc.Unsafe U;
②关键类
// Node类实现了Map.Entry接口,主要存放key-value对,并且具有next域
static class Node<K,V> implements Map.Entry<K,V> {
final int hash;
final K key;
volatile V val;
volatile Node<K,V> next;
.....
}
// 树节点,继承于承载数据的Node类。而红黑树的操作是针对TreeBin类的,从该类的注释也可以看出,TreeBin会将TreeNode进行再一次封装
static final class TreeNode<K,V> extends Node<K,V> {
TreeNode<K,V> parent; // red-black tree links
TreeNode<K,V> left;
TreeNode<K,V> right;
TreeNode<K,V> prev; // needed to unlink next upon deletion
boolean red;
.....
}
// 这个类并不负责包装用户的key、value信息,而是包装的很多TreeNode节点。实际的ConcurrentHashMap“数组”中,存放的是TreeBin对象,而不是TreeNode对象
static final class TreeBin<K,V> extends Node<K,V> {
TreeNode<K,V> root;
volatile TreeNode<K,V> first;
volatile Thread waiter;
volatile int lockState;
// values for lockState
static final int WRITER = 1; // set while holding write lock
static final int WAITER = 2; // set when waiting for write lock
static final int READER = 4; // increment value for setting read lock
.....
}
// 在扩容时才会出现的特殊节点,其key,value,hash全部为null,并拥有nextTable指针引用新的table数组
static final class ForwardingNode<K,V> extends Node<K,V> {
final Node<K,V>[] nextTable;
ForwardingNode(Node<K,V>[] tab) {
super(MOVED, null, null, null);
this.nextTable = tab;
}
.....
}
三、:重点方法分析
①构造方法
// 默认初始化,容量大小为16
public ConcurrentHashMap() {
}
// 根据指定容量进行初始化
public ConcurrentHashMap(int initialCapacity) {
// 小于0直接抛异常
if (initialCapacity < 0)
throw new IllegalArgumentException();
// 判断是否超过了允许的最大值,超过了则取最大值,否则再对该值进一步处理
int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1)) ?
MAXIMUM_CAPACITY :
tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
// 赋值给sizeCtl
this.sizeCtl = cap;
}
// 根据指定map进行初始化
public ConcurrentHashMap(Map<? extends K, ? extends V> m) {
this.sizeCtl = DEFAULT_CAPACITY;
putAll(m);
}
// 根据指定容量、加载因子进行初始化
public ConcurrentHashMap(int initialCapacity, float loadFactor) {
this(initialCapacity, loadFactor, 1);
}
// 根据指定容量、加载因子、并发度(预计同时操作数据的线程)进行初始化
public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();
if (initialCapacity < concurrencyLevel) // Use at least as many bins
initialCapacity = concurrencyLevel; // as estimated threads
long size = (long)(1.0 + (long)initialCapacity / loadFactor);
int cap = (size >= (long)MAXIMUM_CAPACITY) ?
MAXIMUM_CAPACITY : tableSizeFor((int)size);
this.sizeCtl = cap;
}
从根据指定容量进行初始化的构造方法中,可以看到最终将cap赋值给sizeCtl,也说明了当调用构造器方法之后,sizeCtl的大小应该就代表了ConcurrentHashMap的大小,即table数组长度。
private static final int tableSizeFor(int c) {
int n = c - 1;
n |= n >>> 1;
n |= n >>> 2;
n |= n >>> 4;
n |= n >>> 8;
n |= n >>> 16;
return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}
该方法会将调用构造器方法时指定的容器大小转换成一个2的幂次方数,也就是说ConcurrentHashMap的大小一定是2的幂。比如,当指定大小为18时,为了满足2的幂次方特性,实际上concurrentHashMapd的大小为2的5次方(32)。
另外,需要注意的是,调用构造器方法的时候并未构造出table数组(可以理解为ConcurrentHashMap的数据容器),只是算出table数组的长度,当第一次向ConcurrentHashMap插入数据的时候才真正的完成初始化创建table数组的工作。
构造方法与HashMap对比可以发现,没有了HashMap中的threshold和loadFactor,而是改用了sizeCtl来控制,而且只存储了容量在里面,那么它是怎么用的呢?官方给出的解释如下:
●-1,表示有线程正在进行初始化操作。
●-(1 + nThreads),表示有n个线程正在一起扩容。
●0,默认值,后续在真正初始化的时候使用默认容量。
●> 0,初始化或扩容完成后下一次的扩容门槛。
②initTable()方法
private final Node<K,V>[] initTable() {
Node<K,V>[] tab; int sc;
while ((tab = table) == null || tab.length == 0) {
// 保证只有一个线程正在进行初始化操作
if ((sc = sizeCtl) < 0)
Thread.yield(); // lost initialization race; just spin
else if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) {
try {
// 再次检查table是否为空,防止ABA问题
if ((tab = table) == null || tab.length == 0) {
// 如果table大小为0,设置为默认值16
int n = (sc > 0) ? sc : DEFAULT_CAPACITY;
@SuppressWarnings("unchecked")
// 真正的初始化table
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n];
table = tab = nt;
// 计算table中可用的大小:实际大小n*0.75(加载因子)
sc = n - (n >>> 2);
}
} finally {
sizeCtl = sc;
}
break;
}
}
return tab;
}
有可能多个线程同时走到这个方法中,为了保证能够正确初始化,会先通过if进行判断,若当前已经有一个线程正在初始化即sizeCtl值变为-1,这个时候其他线程在if处判断为true从而调用Thread.yield()让出CPU时间片。正在进行初始化的线程会调用U.compareAndSwapInt方法将sizeCtl改为-1即正在初始化的状态。
另外还有一个有意思的二进制操作:在计算数组中可用的大小即为数组实际大小n乘以加载因子0.75。可以看看这里乘以0.75的算法:0.75为四分之三,这里n - (n >>> 2)刚好是n-(1/4)n=(3/4)n。如果选择是无参的构造器的话,这里在new Node数组的时候会使用默认大小为DEFAULT_CAPACITY(16),然后乘以加载因子0.75为12,也就是说数组的可用大小为12。同时我们可以发现,对应HashMap中的threshold和loadFactor,在ConcurrentHashMap中其实是写死的。
③put()方法
public V put(K key, V value) {
return putVal(key, value, false);
}
final V putVal(K key, V value, boolean onlyIfAbsent) {
// key和value都不能为null
if (key == null || value == null) throw new NullPointerException();
// 计算key的hash值
int hash = spread(key.hashCode());
// 要插入的元素所在table的元素计数
int binCount = 0;
// 自旋操作
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
// 如果当前table还没有初始化先调用initTable()方法将table进行初始化
if (tab == null || (n = tab.length) == 0)
tab = initTable();
// 如果table中索引为i的位置的元素为null,则直接使用CAS将值插入即可
else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
if (casTabAt(tab, i, null,
new Node<K,V>(hash, key, value, null)))
break; // no lock when adding to empty bin
}
// 当前正在扩容
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
synchronized (f) {
// 再次检测table第一个元素是否有变化,如果有变化则进入下一次循环,从头来过
if (tabAt(tab, i) == f) {
// 当前为链表,在链表中插入新的键值对
if (fh >= 0) {
// 元素计数赋值为1,之后每次遍历值+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)))) {
// 如果找到了这个元素,则赋值为新值,并退出循环
oldVal = e.val;
if (!onlyIfAbsent)
e.val = value;
break;
}
Node<K,V> pred = e;
// 如果到链表尾部还没有找到元素,就把它插入到链表结尾并退出循环
if ((e = e.next) == null) {
pred.next = new Node<K,V>(hash, key,
value, null);
break;
}
}
}
// 当前为红黑树,将新的键值对插入到红黑树中
else if (f instanceof TreeBin) {
Node<K,V> p;
// 元素计数赋值为2
binCount = 2;
// 调用红黑树的插入方法插入元素,成功插入则返回null,失败则返回寻找到的节点
if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
// 插入完键值对后,再根据实际大小看是否需要转换成红黑树
if (binCount != 0) {
// 如果链表元素计数达到了8,则尝试转化为红黑树
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
// 如果要插入的元素已经存在,则返回旧值
if (oldVal != null)
return oldVal;
break;
}
}
}
// 对当前容量大小进行检查,如果超过了临界值(实际大小*加载因子)就需要扩容
addCount(1L, binCount);
return null;
}
static final int MOVED = -1; // hash for forwarding nodes
可以看到,当出现哈希冲突的时候,使用的是标准的链地址的解决方式:将hash值相同的节点构成链表的形式,称为“拉链法”。另外,在JDK1.8版本中为了防止拉链过长,当链表的长度大于8的时候会将链表转换成红黑树。
代码从整体而言,为了解决线程安全的问题,ConcurrentHashMap使用了synchronzied和CAS的方式。具体步骤如下:
●对于每一个传入的值,首先利用spread()方法对key的hashcode进行一次hash计算,由此来确定这个值在table中的位置。
●如果当前table还未初始化,先将table进行初始化操作。
●如果这个位置为null,那么使用CAS操作直接放入。
●如果这个位置存在结点,说明发生了hash碰撞,首先判断这个节点的类型:
如果该节点fh==MOVED(代表forwardingNode,数组正在进行扩容)的话,说明正在进行扩容。此时利用当前线程去帮忙转移数据。
如果是链表节点(fh>0),则得到的结点就是hash值相同的节点组成的链表的头节点。需要依次向后遍历确定这个新加入的值所在位置。如果遇到key相同的节点,则只需要覆盖该结点的value值即可。否则依次向后遍历,直到链表尾插入这个结点。
如果这个节点的类型是TreeBin的话,直接调用红黑树的插入方法进行插入新的节点。
●插入完节点之后再次检查链表长度,如果长度大于8,就把这个链表转换成红黑树。
●对当前容量大小进行检查,如果超过了临界值(实际大小*加载因子)就需要扩容。
1、spread()方法
static final int spread(int h) {
return (h ^ (h >>> 16)) & HASH_BITS;
}
对于一个hash表来说,hash值分散的不够均匀的话会大大增加哈希冲突的概率,从而影响到hash表的性能。因此通过spread方法进行了一次重hash从而大大减小哈希冲突的可能性。
主要做法是将key的hashCode的低16位与高16位进行异或运算,这样不仅能够使得hash值能够分散能够均匀减小hash冲突的概率。另外只用到了异或运算,在性能开销上也能兼顾。
2、addCount()方法
private final void addCount(long x, int check) {
CounterCell[] as; long b, s;
// 先尝试把数量加到baseCount上,如果失败再加到分段的CounterCell上
if ((as = counterCells) != null ||
!U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
CounterCell a; long v; int m;
boolean uncontended = true;
if (as == null || (m = as.length - 1) < 0 ||
(a = as[ThreadLocalRandom.getProbe() & m]) == null ||
!(uncontended =
U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
fullAddCount(x, uncontended);
return;
}
if (check <= 1)
return;
// 计算元素个数
s = sumCount();
}
if (check >= 0) {
Node<K,V>[] tab, nt; int n, sc;
// 如果元素个数达到了扩容门槛,则进行扩容
while (s >= (long)(sc = sizeCtl) && (tab = table) != null &&
(n = tab.length) < MAXIMUM_CAPACITY) {
// rs是扩容时的一个Stamp标识
int rs = resizeStamp(n);
// sc<0,说明正在扩容中
if (sc < 0) {
// 扩容已经完成了,退出循环
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || (nt = nextTable) == null ||
transferIndex <= 0)
break;
// 扩容未完成,则当前线程加入迁移元素中,并把扩容线程数加1
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
transfer(tab, nt);
}
// 触发扩容的那个线程进入这里
// sizeCtl的高16位存储着rs
// sizeCtl的低16位存储着扩容线程数加1,即(1+nThreads)
else if (U.compareAndSwapInt(this, SIZECTL, sc,
(rs << RESIZE_STAMP_SHIFT) + 2))
transfer(tab, null);
// 重新计算元素个数
s = sumCount();
}
}
}
这里发现,原理跟LongAdder非常类似。(好吧,其实是源码注释里说的)
代码主要流程如下:
●元素个数存储在不同的段上,减少不同线程同时更新size时的冲突。
●计算元素个数时把这些段的值及baseCount相加算出总的元素个数。
●正常情况下sizeCtl存储着扩容门槛,扩容门槛为容量的0.75倍。
●扩容时sizeCtl高位存储Stamp标识(resizeStamp),低位存储扩容线程数加1(1+nThreads)。
●其它线程添加元素后如果发现存在扩容,也会加入的扩容行列中来。
ⅰ、fullAddCount()
private final void fullAddCount(long x, boolean wasUncontended) {
int h;
if ((h = ThreadLocalRandom.getProbe()) == 0) {
ThreadLocalRandom.localInit(); // force initialization
h = ThreadLocalRandom.getProbe();
wasUncontended = true;
}
boolean collide = false; // True if last slot nonempty
for (;;) {
CounterCell[] as; CounterCell a; int n; long v;
if ((as = counterCells) != null && (n = as.length) > 0) {
if ((a = as[(n - 1) & h]) == null) {
if (cellsBusy == 0) { // Try to attach new Cell
CounterCell r = new CounterCell(x); // Optimistic create
if (cellsBusy == 0 &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
boolean created = false;
try { // Recheck under lock
CounterCell[] rs; int m, j;
if ((rs = counterCells) != null &&
(m = rs.length) > 0 &&
rs[j = (m - 1) & h] == null) {
rs[j] = r;
created = true;
}
} finally {
cellsBusy = 0;
}
if (created)
break;
continue; // Slot is now non-empty
}
}
collide = false;
}
else if (!wasUncontended) // CAS already known to fail
wasUncontended = true; // Continue after rehash
else if (U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))
break;
else if (counterCells != as || n >= NCPU)
collide = false; // At max size or stale
else if (!collide)
collide = true;
else if (cellsBusy == 0 &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
try {
if (counterCells == as) {// Expand table unless stale
CounterCell[] rs = new CounterCell[n << 1];
for (int i = 0; i < n; ++i)
rs[i] = as[i];
counterCells = rs;
}
} finally {
cellsBusy = 0;
}
collide = false;
continue; // Retry with expanded table
}
h = ThreadLocalRandom.advanceProbe(h);
}
else if (cellsBusy == 0 && counterCells == as &&
U.compareAndSwapInt(this, CELLSBUSY, 0, 1)) {
boolean init = false;
try { // Initialize table
if (counterCells == as) {
CounterCell[] rs = new CounterCell[2];
rs[h & 1] = new CounterCell(x);
counterCells = rs;
init = true;
}
} finally {
cellsBusy = 0;
}
if (init)
break;
}
else if (U.compareAndSwapLong(this, BASECOUNT, v = baseCount, v + x))
break; // Fall back on using base
}
}
此处代码及其关联方法,都与LongAdder中实现类似,不再赘述。
3、helpTransfer()方法
final Node<K,V>[] helpTransfer(Node<K,V>[] tab, Node<K,V> f) {
Node<K,V>[] nextTab; int sc;
// 如果table不为空,并且当前table第一个元素为ForwardingNode类型,并且nextTab不为空
// 说明当前table已经迁移完毕了,才去帮忙迁移其它table的元素
// 扩容时会把旧table的第一个元素置为ForwardingNode,并让其nextTab指向新table
if (tab != null && (f instanceof ForwardingNode) &&
(nextTab = ((ForwardingNode<K,V>)f).nextTable) != null) {
int rs = resizeStamp(tab.length);
// sizeCtl<0,说明正在扩容
while (nextTab == nextTable && table == tab &&
(sc = sizeCtl) < 0) {
if ((sc >>> RESIZE_STAMP_SHIFT) != rs || sc == rs + 1 ||
sc == rs + MAX_RESIZERS || transferIndex <= 0)
break;
// 扩容线程数加1
if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1)) {
// 当前线程帮忙迁移元素
transfer(tab, nextTab);
break;
}
}
return nextTab;
}
return table;
}
线程添加元素时发现正在扩容且当前元素所在的table元素已经迁移完成了,则协助迁移其它table的元素。
④transfer()方法
private final void transfer(Node<K,V>[] tab, Node<K,V>[] nextTab) {
int n = tab.length, stride;
if ((stride = (NCPU > 1) ? (n >>> 3) / NCPU : n) < MIN_TRANSFER_STRIDE)
stride = MIN_TRANSFER_STRIDE; // subdivide range
// 如果nextTab为空,说明还没开始迁移
if (nextTab == null) { // initiating
try {
// 新建一个新数组,容量为原来的2倍
@SuppressWarnings("unchecked")
Node<K,V>[] nt = (Node<K,V>[])new Node<?,?>[n << 1];
nextTab = nt;
} catch (Throwable ex) { // try to cope with OOME
sizeCtl = Integer.MAX_VALUE;
return;
}
nextTable = nextTab;
transferIndex = n;
}
int nextn = nextTab.length;
// 新建一个ForwardingNode类型的节点,并把新数组存储在里面
ForwardingNode<K,V> fwd = new ForwardingNode<K,V>(nextTab);
boolean advance = true;
boolean finishing = false; // to ensure sweep before committing nextTab
for (int i = 0, bound = 0;;) {
Node<K,V> f; int fh;
// 整个while循环就是在算i的值,i会从n-1依次递减,n是旧数组的大小
while (advance) {
int nextIndex, nextBound;
if (--i >= bound || finishing)
advance = false;
else if ((nextIndex = transferIndex) <= 0) {
i = -1;
advance = false;
}
else if (U.compareAndSwapInt
(this, TRANSFERINDEX, nextIndex,
nextBound = (nextIndex > stride ?
nextIndex - stride : 0))) {
bound = nextBound;
i = nextIndex - 1;
advance = false;
}
}
// 如果一次遍历完成了,整个map所有table中的元素都迁移完成了
if (i < 0 || i >= n || i + n >= nextn) {
int sc;
// 如果全部迁移完成了,则替换旧数组,并设置下一次扩容门槛为新数组容量的0.75倍
if (finishing) {
nextTable = null;
table = nextTab;
sizeCtl = (n << 1) - (n >>> 1);
return;
}
// 当前线程扩容完成,把扩容线程数-1
if (U.compareAndSwapInt(this, SIZECTL, sc = sizeCtl, sc - 1)) {
if ((sc - 2) != resizeStamp(n) << RESIZE_STAMP_SHIFT)
return;
// 把finishing设置为true(方便进入上一个if条件)
finishing = advance = true;
// i重新赋值为n,这样会再重新遍历一次数组,看看是不是都迁移完成了(也就是下面的(fh = f.hash) == MOVED这个条件)
i = n; // recheck before commit
}
}
// 如果table中无数据,直接放入ForwardingNode标记该table已迁移
else if ((f = tabAt(tab, i)) == null)
advance = casTabAt(tab, i, null, fwd);
// 如果table中第一个元素的hash值为MOVED,说明它是ForwardingNode节点,也就是该table已迁移
else if ((fh = f.hash) == MOVED)
advance = true; // already processed
else {
synchronized (f) {
// 再次判断当前table第一个元素是否有修改(可能其它线程先一步迁移了元素)
if (tabAt(tab, i) == f) {
// 把一个table分化成两个table,规则是table中各元素的hash与table大小n进行与操作
// 等于0的放到低位table(low)中,不等于0的放到高位table(high)中
// 其中低位table迁移到新table中的位置相对旧table不变,高位table迁移到新table中位置正好是其在旧table的位置加n
// 这也正是为什么扩容时容量在变成两倍的原因
Node<K,V> ln, hn;
// 第一个元素的hash值大于等于0,说明该table中元素是以链表形式存储的
if (fh >= 0) {
// 这里与HashMap迁移算法基本类似,唯一不同的是多了一步寻找lastRun
// 这里的lastRun是提取出链表后面不用处理再特殊处理的子链表
// 比如所有元素的hash值与table大小n与操作后的值分别为 0 0 4 4 0 0 0
// 则最后后面三个0对应的元素肯定还是在同一个table中
// 这时lastRun对应的就是倒数第三个节点
int runBit = fh & n;
Node<K,V> lastRun = f;
for (Node<K,V> p = f.next; p != null; p = p.next) {
int b = p.hash & n;
if (b != runBit) {
runBit = b;
lastRun = p;
}
}
// 判断最后这几个元素归属于低位链表还是高位链表
if (runBit == 0) {
ln = lastRun;
hn = null;
}
else {
hn = lastRun;
ln = null;
}
// 遍历链表,把hash&n为0的放在低位链表中,不为0的放在高位链表中
for (Node<K,V> p = f; p != lastRun; p = p.next) {
int ph = p.hash; K pk = p.key; V pv = p.val;
if ((ph & n) == 0)
ln = new Node<K,V>(ph, pk, pv, ln);
else
hn = new Node<K,V>(ph, pk, pv, hn);
}
// 低位链表的位置不变
setTabAt(nextTab, i, ln);
// 高位链表的位置是原位置加n
setTabAt(nextTab, i + n, hn);
// 标记当前table已迁移
setTabAt(tab, i, fwd);
// advance设置为true,返回上面进行--i操作
advance = true;
}
// 如果第一个元素是树节点,也是一样,分化成两颗树
else if (f instanceof TreeBin) {
TreeBin<K,V> t = (TreeBin<K,V>)f;
TreeNode<K,V> lo = null, loTail = null;
TreeNode<K,V> hi = null, hiTail = null;
int lc = 0, hc = 0;
// 遍历整颗树,根据hash&n是否为0分化成两颗树(为0放在低位树中,不为0放在高位树中)
for (Node<K,V> e = t.first; e != null; e = e.next) {
int h = e.hash;
TreeNode<K,V> p = new TreeNode<K,V>
(h, e.key, e.val, null, null);
if ((h & n) == 0) {
if ((p.prev = loTail) == null)
lo = p;
else
loTail.next = p;
loTail = p;
++lc;
}
else {
if ((p.prev = hiTail) == null)
hi = p;
else
hiTail.next = p;
hiTail = p;
++hc;
}
}
// 如果分化的树中元素个数小于等于6,则退化成链表
ln = (lc <= UNTREEIFY_THRESHOLD) ? untreeify(lo) :
(hc != 0) ? new TreeBin<K,V>(lo) : t;
hn = (hc <= UNTREEIFY_THRESHOLD) ? untreeify(hi) :
(lc != 0) ? new TreeBin<K,V>(hi) : t;
// 低位树的位置不变
setTabAt(nextTab, i, ln);
// 高位树的位置是原位置加n
setTabAt(nextTab, i + n, hn);
// 标记该table已迁移
setTabAt(tab, i, fwd);
// advance设置为true,返回上面进行--i操作
advance = true;
}
}
}
}
}
}
代码主要流程如下:
●新数组大小变更为旧数组的两倍。
●迁移元素先从靠后的table开始。
●迁移完成的table在里面放置一个ForwardingNode类型的元素,标记该table迁移完成。
●迁移时根据hash&n是否等于0把table中元素分化成两个链表或树。
●低位链表(树)存储在原来的位置,高位链表(树)存储在原来的位置加n的位置。
●迁移元素时会锁住当前table,也是分段锁的思想。
⑤get()方法
public V get(Object key) {
Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
// 计算key的hash值
int h = spread(key.hashCode());
// 如果元素所在的table存在且里面有元素
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
// 如果第一个元素就是要找的元素,直接返回
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
// hash小于0,说明是树或者正在扩容,使用find()方法寻找元素(find依据Node的不同子类有不同的实现方式)
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
// 遍历整个链表寻找元素
while ((e = e.next) != null) {
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
代码主要流程如下:
●对于每一个传入的值,首先利用spread()方法对key的hashcode进行一次hash计算,由此来确定这个值在table中的位置。
●如果table中第一个元素就是该找的元素,直接返回。
●如果元素存储类型是树 或者 正在迁移元素,则调用各自Node子类的find()方法寻找元素。
●如果元素存储类型是链表,遍历整个链表寻找元素。
●获取元素没有加锁。
⑥remove()方法
public V remove(Object key) {
return replaceNode(key, null, null);
}
final V replaceNode(Object key, V value, Object cv) {
// 计算key的hash值
int hash = spread(key.hashCode());
// 自旋
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
// 如果目标key所在的table不存在,跳出循环返回null
if (tab == null || (n = tab.length) == 0 ||
(f = tabAt(tab, i = (n - 1) & hash)) == null)
break;
// 如果正在扩容中,协助扩容
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
// 标记是否处理过
boolean validated = false;
synchronized (f) {
// 再次验证当前table第一个元素是否被修改过
if (tabAt(tab, i) == f) {
// 如果是链表节点
if (fh >= 0) {
validated = true;
// 遍历链表寻找目标节点
for (Node<K,V> e = f, pred = null;;) {
K ek;
// 找到目标节点
if (e.hash == hash &&
((ek = e.key) == key ||
(ek != null && key.equals(ek)))) {
V ev = e.val;
// 检查目标节点旧value是否等于传入的cv
if (cv == null || cv == ev ||
(ev != null && cv.equals(ev))) {
oldVal = ev;
// 如果value不为空则替换旧值
if (value != null)
e.val = value;
// 如果前置节点不为空则删除当前节点
else if (pred != null)
pred.next = e.next;
// 如果前置节点为空,说明是table中第一个元素,删除之
else
setTabAt(tab, i, e.next);
}
break;
}
pred = e;
// 遍历到链表尾部还没找到元素,跳出循环
if ((e = e.next) == null)
break;
}
}
// 如果是树节点
else if (f instanceof TreeBin) {
validated = true;
TreeBin<K,V> t = (TreeBin<K,V>)f;
TreeNode<K,V> r, p;
// 遍历树找到目标节点
if ((r = t.root) != null &&
(p = r.findTreeNode(hash, key, null)) != null) {
V pv = p.val;
// 检查目标节点旧value是否等于传入的cv
if (cv == null || cv == pv ||
(pv != null && cv.equals(pv))) {
oldVal = pv;
// 如果value不为空则替换旧值
if (value != null)
p.val = value;
// 如果value为空则删除元素,如果删除后树的元素个数较少则退化成链表(t.removeTreeNode(p)这个方法返回true表示删除节点后树的元素个数较少)
else if (t.removeTreeNode(p))
setTabAt(tab, i, untreeify(t.first));
}
}
}
}
}
// 如果处理过,不管有没有找到元素都返回
if (validated) {
// 如果找到了元素,返回其旧值
if (oldVal != null) {
// 如果要替换的值为空,元素个数减1
if (value == null)
addCount(-1L, -1);
return oldVal;
}
break;
}
}
}
// 没找到元素返回空
return null;
}
代码主要流程如下:
●对于每一个传入的值,首先利用spread()方法对key的hashcode进行一次hash计算,由此来确定这个值在table中的位置。
●如果所在的table不存在,表示没有找到目标元素,返回null。
●如果发现正在扩容,则协助扩容完成后再进行删除操作。
●如果是以链表形式存储的,则遍历整个链表查找元素,找到之后再删除。
●如果是以树形式存储的,则遍历树查找元素,找到之后再删除。删除元素之后如果树较小,则退化成链表。
●如果确实删除了元素,则整个map元素个数减1,并返回旧值。
●如果没有删除元素,则返回null。
四、:总结
根据上面的源码学习,我们可以得出一些ConcurrentHashMap相关的特性、表现等,有些内容面试时也可能经常问到,不建议死记硬背,理解才是王道:
●ConcurrentHashMap是HashMap的线程安全版本。(根据使用者的使用方法也可能线程不安全,不要过度信仰)
●ConcurrentHashMap采用 数组 + 链表 + 红黑树 的结构存储元素。
●ConcurrentHashMap相比于同样线程安全的HashTable,效率要高很多。
●ConcurrentHashMap中不能存储key或value为null的元素。
●ConcurrentHashMap采用的保障线程安全手段有:synchronized、CAS、自旋锁、分段锁、volatile等。
●ConcurrentHashMap中没有threshold和loadFactor这两个字段,而是采用sizeCtl来代替控制。(其值含义见上文)整个扩容过程都是通过CAS控制sizeCtl这个字段来进行的。
●更新、删除等操作时如果发现正在进行扩容,当前线程协助扩容。迁移完元素的table会放置一个ForwardingNode节点,以标识该table迁移完毕。
●更新、删除等操作会采用synchronized锁住当前table的第一个元素,这是分段锁的思想。
●元素个数的存储也是采用的分段思想,类似于LongAdder的实现。元素个数的更新会把不同的线程hash到不同的段上,减少资源争用。元素个数的更新如果还是出现多个线程同时更新一个段,则会扩容段(CounterCell)。获取元素个数是把所有的段(包括baseCount和CounterCell)相加起来得到的。
●查询操作是不加锁的,所以ConcurrentHashMap不是强一致性的。
系列文章传送门:
JUC探险-1、初识概貌
JUC探险-2、synchronized
JUC探险-3、volatile
JUC探险-4、final
JUC探险-5、原子类
JUC探险-6、Lock & AQS
JUC探险-7、ReentrantLock
JUC探险-8、ReentrantReadWriteLock
JUC探险-9、Condition
JUC探险-10、常见工具、数据结构
JUC探险-11、ConcurrentHashMap
JUC探险-12、CopyOnWriteArrayList
JUC探险-13、ConcurrentLinkedQueue
JUC探险-14、ConcurrentSkipListMap
JUC探险-15、BlockingQueue
JUC探险-16、ThreadLocal
JUC探险-17、线程池