目录
概述
ConcurrentHashMap相当于是HashMap的多线程版本,它的功能本质上和HashMap没什么区别。因为HashMap在并发操作的时候会出现各种问题,比如死循环问题、数据覆盖等问题。而这些问题,只要使用ConcurrentHashMap就可以完美地解决。那问题来到了,ConcurrentHashMap它是如何保证线程安全的呢?
1、JDK1.7实现原理
首先,我们来看JDK1.7中ConcurrentHashMap的底层结构,它基本延续了HashMap的设计,采用的是数组加链表的形式。和HashMap不同的是,ConcurrentHashMap中的数组设计分为大数组Segment和小数组HashEntry,来着这张图。
大树组Segment可以理解为一个数据库,而每个数据库(Segment)中又有很多张表(HashEntry),每个HashEntry中又有很多条数据,这些数据是用链表连接的。了解了ConcurrentHashMap的基本结构设计,我们再来看它的线程安全实现,就比较简单了。
接下来我们来对照JDK1.7中ConcurrentHashMap的put()方法源码实现。
因为Segment本身是基于ReentrantLock重入锁实现的加锁和释放锁的操作,这样就能保证多个线程同时访问ConcurrentHashMap时,同一时间只能有一个线程能够操作相应的节点,这样就保证了ConcurrentHashMap的线程安全。
也就是说ConcurrentHashMap的线程安全是建立在Segment加锁的基础上的,所以,我们称它为分段锁或者片段锁,如图中所示。
那JDK1.8又是如何实现的呢?
2、JDK1.8优化内容
在JDK1.7中,ConcurrentHashMap虽然是线程安全的,但因为它的底层实现是数组加链表的形式,所以在数据比较多情况下,因为要遍历整个链表,会降低访问性能。所以,JDK1.8以后采用了数组加链表加红黑树的方式优化了ConcurrentHashMap的实现,具体实现如图所示:
当链表长度大于8,并且数组长度大于64时,链表就会升级为红黑树的结构。JDK1.8中的ConcurrentHashMap虽然保留了Segment的定义,但这,仅仅是为了保证序列化时的兼容性,不再有任何结构上的用处了。
那在JDK1.8中ConcurrentHashMap的源码是如何实现的呢?它主要是使用了CAS加volatile或者synchronized的方式来保证线程安全。
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;
if (tab == null || (n = tab.length) == 0)
tab = initTable();
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) {
if (tabAt(tab, i) == f) {
if (fh >= 0) {
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;
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;
}
我们可以从源码片段中看到,添加元素时首先会判断容器是否为空,如果为空则使用 volatile 加 CAS 来初始化,如果容器不为空 ,则根据存储的元素计算该位置是否为空。
如果根据存储的元素计算结果为空则利用 CAS 设置该节点;
如果根据存储的元素计算为空不为空,则使用synchronized,然后,遍历桶中的数据,并替换或新增节点到桶中,最后再判断是否需要转为红黑树。这样就能保证并发访问时的线程安全了。
如果把上面的执行用一句话归纳的话,就相当于是ConcurrentHashMap通过对头结点加锁来保证线程安全的。
这样设计的好处是,使得锁的粒度相比Segment来说更小了,发生hash冲突和加锁的频率也降低了,在并发场景下的操作性能也提高了。而且,当数据量比较大的时候,查询性能也得到了很大的提升。
3、总结
最后,我们来总结一下:
1、ConcurrentHashMap在JDK1.7中使用的数组加链表的结构,其中数组分为两类,大树组Segment和小数组HashEntry,而加锁是通过给Segment添加ReentrantLock重入锁来保证线程安全的。
2、ConcurrentHashMap在JDK1.8中使用的是数组加链表加红黑树的方式实现,它是通过CAS或者synchronized来保证线程安全的,并且缩小了锁的粒度,查询性能也更高。
ConcurrentHashMap中有很多设计思想是值得我们去学习和借鉴的,比如说锁的粒度控制、分段锁的设计等等,都可以应用在实际的业务开发场景中。我们通过学习这些底层原理从中获取很多的设计思路,帮助我们更高效地去解决实际问题。