1 概述
前面我们分析了ConcurrentHashMap(JDK1.7)(请参考JUC–ConcurrentHashMap源码分析(一)(基于JDK1.7))和HashMap(JDK1.8)(请参考Java集合框架–HashMap源码分析(二)(基于JDK1.8))的源码,我们直到ConcurrentHashMap其实就是针对HashMap(JDK1.7)进行了分段加锁的方式,也就是针对HashTable中的对整个table进行加锁,改成了将table分成很多段,然后对对应的段进行加锁。
ConcurrentHashMap(JDK1.8)其实就是在HashMap(JDK1.8)的基础上,使用CAS和sychronized关键字来对table中的节点进行加锁,这里就进一步减小了锁的粒度。下面我们就开始来看一下ConcurrentHashMap(JDK1.8)的具体实现。
2 数据结构
ConcurrentHashMap(JDK1.8)在数据的结构上加入了红黑树,从而对查询的效率进行了进一步优化,同时屏弃了JDK1.7中的Segment分段加锁的方式,改成CAS和sychronized来保证并发安全性。具体的数据结构图如下:
3 内部类
(1)Node
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其实和HashEntry是相同的,这里就不多说了。
(2)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;
TreeNode(int hash, K key, V val, Node<K,V> next,
TreeNode<K,V> parent) {
super(hash, key, val, next);
this.parent = parent;
}
... ...
从上面的源码我们可以看出,TreeNode静态内部类实现了典型的红黑树的数据结构。
(3)TreeBin
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
... ...
TreeBean相当于一个TreeNode的容器,里面也提供了针对红黑树结构的添加和删除的操作函数。
4属性
针对属性这里就不做统一分析说明了,其实和HashMap(JDK1.8)中的属性类似。
5 构造函数
针对ConcurrentHashMap的构造函数,我们仅仅分析一个比较核心的构造函数即可。
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
初始化table的大小
long size = (long)(1.0 + (long)initialCapacity / loadFactor);
int cap = (size >= (long)MAXIMUM_CAPACITY) ?
MAXIMUM_CAPACITY : tableSizeFor((int)size);
this.sizeCtl = cap;
}
上面的构造函数有一个比较陌生的参数concurrencyLevel,这个参数我们可以理解成用于控制有多少个线程可以同时操作Current HashMap。
6 核心函数
针对核心函数,我们这里还是分析put和get两种函数。
6.1 put函数
首先,我们直接上源码,并在源码中对关键逻辑处进行注释。
final V putVal(K key, V value, boolean onlyIfAbsent) {
if (key == null || value == null) throw new NullPointerException();
int hash = spread(key.hashCode());
int binCount = 0;
for (Node<K,V>[] tab = table;;) {
Node<K,V> f; int n, i, fh;
//如果table不存在或者为空,则初始化table
if (tab == null || (n = tab.length) == 0)
tab = initTable();
//如果table对应位置的Node为空,则直接在对应位置使用CAS设置Node。
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
}
//如果当前节点的hash == MOVED == -1,则需要进行扩容
else if ((fh = f.hash) == MOVED)
tab = helpTransfer(tab, f);
else {
V oldVal = null;
//对table对应位置的节点Node进行加锁
synchronized (f) {
//table对应位置的节点是普通的Node结构
if (tabAt(tab, i) == f) {
if (fh >= 0) {
binCount = 1;
/**
* 在对应链表的对应位置插入节点,如果存在key和hash相等,则替换节点的value值,
* 如果不存在key和hash相等的节点,则生成新的节点,并让最后一个节点的下一个节点指向新
* 节点。
*/
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;
}
}
}
//table对应位置的节点是红黑树结构
else if (f instanceof TreeBin) {
Node<K,V> p;
binCount = 2;
//采用红黑树插入节点的方式插入值
if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
value)) != null) {
oldVal = p.val;
if (!onlyIfAbsent)
p.val = value;
}
}
}
}
if (binCount != 0) {
//当链表长度大于需要转换成红黑树的阀值的时候转换成红黑树
if (binCount >= TREEIFY_THRESHOLD)
treeifyBin(tab, i);
if (oldVal != null)
return oldVal;
break;
}
}
}
addCount(1L, binCount);
return null;
}
从上面的代码我们可以看出,这里替代了之前的对Segment进行加锁,而是当table对应位置的Node为空的时候直接使用CAS来进行设置,当不为空的时候就对table对应位置的节点加锁,然后遍历节点进行操作。
6.2 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数组不为空,并且hash值对应的节点存在
if ((tab = table) != null && (n = tab.length) > 0 &&
(e = tabAt(tab, (n - 1) & h)) != null) {
//如果对table数组中的节点的hash和key都和要查找的key和hash相等,这个时候就直接返回table数组节点的value
if ((eh = e.hash) == h) {
if ((ek = e.key) == key || (ek != null && key.equals(ek)))
return e.val;
}
//eh < 0,是红黑树,按照红黑树的方式获取
else if (eh < 0)
return (p = e.find(h, key)) != null ? p.val : null;
//循环hash对应table位置的链表,如果存在key和hash相等的节点直接返回value
while ((e = e.next) != null) {
if (e.hash == h &&
((ek = e.key) == key || (ek != null && key.equals(ek))))
return e.val;
}
}
return null;
}
get方法的实现比较简单,我们这里就不做过多的解释了。
7 总结
JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap,,ConcurrentHashMap只是增加了同步的操作来控制并发,从JDK1.7版本的ReentrantLock+Segment+HashEntry,到JDK1.8版本中synchronized+CAS+Node+红黑树。
现总结下针对ConcurrentHashMap的JDK1.7和JDK1.8的实现区别:
- JDK1.8的实现降低锁的粒度,JDK1.7版本锁的粒度是基于Segment的,包含多个HashEntry,而JDK1.8锁的粒度就是HashEntry(首节点)
- JDK1.8版本的数据结构变得更加简单,使得操作也更加清晰流畅,因为已经使用synchronized来进行同步,所以不需要分段锁的概念,也就不需要Segment这种数据结构了,由于粒度的降低,实现的复杂度也增加了
- JDK1.8使用红黑树来优化链表,基于长度很长的链表的遍历是一个很漫长的过程,而红黑树的遍历效率是很快的,代替一定阈值的链表,这样形成一个最佳拍档
- JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock,我觉得有以下几点:
- 因为粒度降低了,在相对而言的低粒度加锁方式,synchronized并不比ReentrantLock差,在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界,更加的灵活,而在低粒度中,Condition的优势就没有了
- JVM的开发团队从来都没有放弃synchronized,而且基于JVM的synchronized优化空间更大,使用内嵌的关键字比使用API更加自然
- 在大量的数据操作下,对于JVM的内存压力,基于API的ReentrantLock会开销更多的内存,虽然不是瓶颈,但是也是一个选择依据