ConcurrentHashMap源码分析
1.ConcurrentHashMap原理介绍(JDK1.7)
我们知道HashTable在并发情况下效率低的原因是所有访问HashTable的线程都必须竞争同一把锁，这就导致一旦一个线程获取了锁，其余所有的线程都必须处于等待状态。而ConcurrentHashMap使用的是锁分段技术，就是将数据分为一段一段的存储，给每一段数据都配一把锁，当一个线程占用一把锁访问其中一段数据的时候，其他段的数据也能够被其他线程访问。ConcurrentHashMap是由segment数组构成，segment是一个可重入锁，它的结构和HashMap类似，底层是一个HashEntry数组，看如下图：
2.构造函数
@SuppressWarnings("unchecked")
public ConcurrentHashMap(int initialCapacity,
float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();
if (concurrencyLevel > MAX_SEGMENTS)
concurrencyLevel = MAX_SEGMENTS;
// Find power-of-two sizes best matching arguments
int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {
++sshift;
ssize <<= 1;
}
this.segmentShift = 32 - sshift;
this.segmentMask = ssize - 1;
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
//initialCapacity是ConcurrentHashMap的初始化容量
int c = initialCapacity / ssize;
if (c * ssize < initialCapacity)
++c;
// cap是每个segment的容量，也就是HashEntry数组的长度，它也是一个2的N次幂值
int cap = MIN_SEGMENT_TABLE_CAPACITY;
while (cap < c)
cap <<= 1;
// create segments and segments[0]
// loadFactor是每个segment的负载因子，创建Segments数组，然后初始化每个Segment的值
Segment<K,V> s0 =
new Segment<K,V>(loadFactor, (int)(cap * loadFactor),
(HashEntry<K,V>[])new HashEntry[cap]);
Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize];
UNSAFE.putOrderedObject(ss, SBASE, s0); // ordered write of segments[0]
this.segments = ss;
}
通过以上代码可知：Segment的数组长度ssize是由concurrencyLevel计算出来的，ssize是一个大于等于concurrencyLevel的最小的2的N次幂值。sshift等于ssize从1向左移位的次数，默认情况下会移动4次，即sshift等于4。segmentShift和segmentMask在定位segment的算法中有使用到。
3 方法
3.1 get方法
public V get(Object key) { Segment<K,V> s; // manually integrate access methods to reduce overhead HashEntry<K,V>[] tab;
// 根据key的hash值h，以及之前得到的segmentShift，segmentMask等值得到u，从而定位到segment int h = hash(key); long u = (((h >>> segmentShift) & segmentMask) << SSHIFT) + SBASE; if ((s = (Segment<K,V>)UNSAFE.getObjectVolatile(segments, u)) != null && (tab = s.table) != null) {
// 在定位到Segment后,然后定位到HashEntry数组中的位置，最后通过逐一比较，返回要找的值 for (HashEntry<K,V> e = (HashEntry<K,V>) UNSAFE.getObjectVolatile (tab, ((long)(((tab.length - 1) & h)) << TSHIFT) + TBASE); e != null; e = e.next) { K k; if ((k = e.key) == key || (e.hash == h && key.equals(k))) return e.value; } } return null; }
有两个问题值得思考：一是在上面代码中，使用了UNSAFE.getObjectVolatile(segments, u)来获取segment，为什么不直接使用segments[u]来获取呢？我们知道每个线程都有自己的工作内存，里面存放着segments的副本，在并发环境下，并不能保证每次拿到的是segments中的最新元素。但是使用UNSAFE.getObjectVolatile(segments, u)可以直接获取指定内存的数据，保证拿到的数据是最新的。二是读操作为什么不需要加锁？get方法的高效之处就是不加锁，我们知道HashTable读操作时需要加锁的，那么ConcurrentHashMap是怎么做到的呢?HashEntry中的value值被定义为了volatile类型，这样value就能在多个线程间保持可见性，能够被多个线程读，而不会读到过期的值。一旦有线程修改value值，那么其他线程本地内存中的value值就会失效，从而保证去获取最新的value值，这是volatile代替锁的经典应用场景。
3.2 put方法
@SuppressWarnings("unchecked")
public V put(K key, V value) {
Segment<K,V> s;
if (value == null)
throw new NullPointerException();
// 先根据key，segmentShift,segmentMask定位到segment
int hash = hash(key);
int j = (hash >>> segmentShift) & segmentMask;
if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
(segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
s = ensureSegment(j);
// 然后，将key和value放到segment中 进入该方法
return s.put(key, hash, value, false);
}
final V put(K key, int hash, V value, boolean onlyIfAbsent) {
// put操作需要加锁 HashEntry<K,V> node = tryLock() ? null : scanAndLockForPut(key, hash, value); V oldValue; try { HashEntry<K,V>[] tab = table; int index = (tab.length - 1) & hash; HashEntry<K,V> first = entryAt(tab, index); for (HashEntry<K,V> e = first;;) { if (e != null) { K k; if ((k = e.key) == key || (e.hash == hash && key.equals(k))) { oldValue = e.value; if (!onlyIfAbsent) { e.value = value; ++modCount; } break; } e = e.next; } else { if (node != null) node.setNext(first); else node = new HashEntry<K,V>(hash, key, value, first); int c = count + 1;
// 满足条件，则进行扩容操作 if (c > threshold && tab.length < MAXIMUM_CAPACITY) rehash(node); else setEntryAt(tab, index, node); ++modCount; count = c; oldValue = null; break; } } } finally {
// 解锁 unlock(); } return oldValue; }
在put方法中，需要注意的是扩容时，针对的是某个segment，而不是对整个容器扩容。
3.3 size方法
public int size() { // Try a few times to get accurate count. On failure due to // continuous async changes in table, resort to locking. final Segment<K,V>[] segments = this.segments; int size; boolean overflow; // true if size overflows 32 bits long sum; // sum of modCounts long last = 0L; // previous sum int retries = -1; // first iteration isn't retry try { for (;;) {
// 在尝试三次后，则加锁 if (retries++ == RETRIES_BEFORE_LOCK) { for (int j = 0; j < segments.length; ++j) ensureSegment(j).lock(); // force creation } sum = 0L; size = 0; overflow = false; for (int j = 0; j < segments.length; ++j) { Segment<K,V> seg = segmentAt(segments, j); if (seg != null) { sum += seg.modCount; int c = seg.count; if (c < 0 || (size += c) < 0) overflow = true; } }
// 如果在累加count前后，modCount不变，则跳出循环 if (sum == last) break; last = sum; } } finally {
// 尝试三次后，需要解锁 if (retries > RETRIES_BEFORE_LOCK) { for (int j = 0; j < segments.length; ++j) segmentAt(segments, j).unlock(); } } return overflow ? Integer.MAX_VALUE : size; }
对于获取ConcurrentHashMap中元素的个数，就是把每个segment中count的个数相加即可，但是这里有个问题，在多线程环境下，在累加count的过程中，之前已经累加过的count可能会发生变化，使用加锁处理的话能解决这个问题，但是在累加count操作过程中，之前累加过的count发生变化的几率非常小，那么ConcurrentHashMap是这样解决的：先尝试三次不加锁的方式来累加count，在累加结束前后比较modCount的值是否发生变化；如果发生变化，则再通过加锁的方式来统计累加count。
最后关于ConcurrentHashMap，还有个问题：它的迭代器是强一致性的迭代器还是弱一致性的迭代器？在java.util包中集合类都返回fail-fast迭代器，这就意味着，在集合迭代过程中，如果修改集合内容，则会抛出异常ConcurrentModificationException，这是强一致性迭代器。但是在java.util.concurrent 集合返回的迭代器，是弱一致性迭代器，在遍历过程中，如果已经遍历的集合上的内容变化了，迭代器不会抛出ConcurrentModificationException异常。如果未遍历的数组上的内容发生了变化，则有可能反映到迭代过程中。这就是ConcurrentHashMap迭代器弱一致的表现，这是为了提升效率，是一致性与效率之间的一种权衡。
