本文主要是介绍浅谈java并发容器ConcurrentHashMap,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
我们知道concurrentHashMap是线程安全而且高效的HashMap,至于为什么,我们今天来一探究竟。
HashMap与HashTable
在多线程的环境下使用HashMap进行put操作会使HashMap的Entry链表出现环形链表,从而在get操作时出现死循环,导致CPU利用率接近100%,看看这篇文章《疫苗:JAVA HASHMAP的死循环》,具体就不赘述了。HashTable虽然是线程安全的,但是看其源码,我们不难发现,HashTable是使用synchronized隐式锁来保证线程安全,这种方法在多线程环境下效率极其低下,线程间的资源竞争激烈,并不适合做高并发的容器。而concurrentHashMap采用的锁分段技术,保证了安全的同时有效提高了并发访问的效率。
concurrentHashMap的结构
我们知道HashMap是由HashEntry数组和链表来实现的,concurrentHashMap在此基础上增加了Segment数组。Segment是一种可重入锁(ReetrantLock),用来担当分段锁。一个Segment包含一个HashEntry的数组,每个HashEntry是一个链表结构元素,所以一个Segment守护着一个HashEntry数组里的元素。当需要对HashEntry内的元素操作时,必须要先获得与之对应的Segment锁。
concurrentHashMap类图(图来自并发编程网)
concurrentHashMap结构图
我们来看一下初始化segments数组的源代码。
if (concurrencyLevel > MAX_SEGMENTS)concurrencyLevel = MAX_SEGMENTS;
int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {++sshift;ssize <<= 1;
}
segmentShift = 32 - sshift;
segmentMask = ssize - 1;
this.segments = Segment.newArray(ssize);
由上面的代码可知,segments数组的长度ssize是通过concurrencyLevel计算得出的。为了能通过按位与的散列算法来定位segments数组的索引,必须保证segments数组的长度是2的N次方(power-of-two size),所以必须计算出一个大于或等于concurrencyLevel的最小的2的N次方值来作为segments数组的长度。假如concurrencyLevel等于14、15或16,ssize都会等于16,即容器里锁的个数也是16。
既然ConcurrentHashMap使用分段锁Segment来保护不同段的数据,那么在插入和获取元素的时候,必须先通过散列算法定位到Segment。可以看到ConcurrentHashMap会首先使用Wang/Jenkins hash的变种算法对元素的hashCode进行一次再散列。
private static int hash(int h) {h += (h << 15) ^ 0xffffcd7d;h ^= (h >>> 10);h += (h << 3);h ^= (h >>> 6);h += (h << 2) + (h << 14);return h ^ (h >>> 16);
}
之所以进行再散列,目的是减少散列冲突,使元素能够均匀地分布在不同的Segment上,从而提高容器的存取效率。假如散列的质量差到极点,那么所有的元素都在一个Segment中,不仅存取元素缓慢,分段锁也会失去意义。
ConcurrentHashMap的操作
get方法
public V get(Object key) {int hash = hash(key.hashCode());return segmentFor(hash).get(key, hash);
}
get过程中并没有使用同步控制,而是交给segment去查找,再看Segment中的get方法:
V get(Object key, int hash) {if (count != 0) { // read-volatileHashEntry<K,V> e = getFirst(hash); while (e != null) {if (e.hash == hash && key.equals(e.key)) {V v = e.value;if (v != null) return v;return readValueUnderLock(e); // recheck}e = e.next;}}return null;
}
从segment的get源码可以看出,如果读到的值是空值才会加锁重读。那么ConcurrentHashMap的get操作是如何做到不加锁的呢?原因是它的get方法里将要使用的共享变量都定义成volatile类型,如用于统计当前Segment大小的count字段和用于存储值的HashEntry的value。定义成volatile的变量,能够在线程之间保持可见性,能够被多线程同时读,并且保证不会读到过期的值,但是只能被单线程写(有一种情况可以被多线程写,就是写入的值不依赖于原值),在get操作里只需要读不需要写共享变量count和value,所以可以不用加锁。
transient volatile int count;
volatile V value;
put操作
由于put操作需要修改共享变量,所以为了保证安全必须加锁。put方法首先定位到Segment,然后在Segment里进行插入操作。插入操作需要经历两个步骤,第一步判断是否需要对Segment里的HashEntry数组进行扩容,第二步定位添加元素的位置,然后将其放在HashEntry数组里。
- 是否需要扩容
在插入元素前会先判断Segment里的HashEntry数组是否超过容量(threshold),如果超过阈值,则对数组进行扩容。值得一提的是,Segment的扩容判断比HashMap更恰当,因为HashMap是在插入元素后判断元素是否已经到达容量的,如果到达了就进行扩容,但是很有可能扩容之后没有新元素插入,这时HashMap就进行了一次无效的扩容。 - 怎么扩容
在扩容的时候,首先会创建一个容量是原来容量两倍的数组,然后将原数组里的元素进行再散列后插入到新的数组里。为了高效,ConcurrentHashMap不会对整个容器进行扩容,而只 对某个segment进行扩容。
size操作
要统计整个ConcurrentHashMap里元素的大小,就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量,那么在多线程场景下,是不是直接把所有Segment的count相加就可以得到concurrentHashMap的大小了呢?答案是没那么简单,虽然相加了可以获取每个segment的count最新值,但是有可能在累加前count发生了变化,那么统计结果就不准确了。所以,最安全的做法是在统计size的时候把所有Segment的put、remove和clean方法全部锁住,但是这种做法显然非常低效。
因为在累加count操作过程中,之前累加过的count发生变化的几率非常小,所以ConcurrentHashMap的做法是先尝试两次通过不锁住Segment的方式来统计各个Segment大小,如果统计的过程中,count发生了变化,再采用加锁的方式来统计所有Segment的大小。
最后值得一提的是,如果你的环境要求“强一致性”的话,就不能用ConcurrentHashMap了,其get,clear方法和迭代器都是“弱一致性”的,若需要“强一致性”,需使用集合的synchronized版本。
文章参考
深入剖析ConcurrentHashMap(2)
聊聊并发(四)深入分析ConcurrentHashMap
这篇关于浅谈java并发容器ConcurrentHashMap的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!