ConcurrentHashMap为什么高效?
在HashTable中，实现线程安全是通过使用synchronized来保证的，但是，当线程之间的竞争非常激烈的时候，HashTable的效率是非常低下的，就例如:当线程A在使用put操作时,此时线程B和线程C如果想要对HashTable进行put或者get操作，因为线程A已经持有了锁，线程B和C只能等待线程A释放锁。这样就导致了当竞争激烈的时候，许多线程处于等待甚至是阻塞状态，处理效率自然就非常低下。
与Hashtable不同，为了解决这种效率低下的问题，JDK1.7版本中的ConcurrentHashMap使用了分段锁技术。所谓分段技术，其实就是将ConcurrentHashMap容器的数据分段存储，每一段数据分配一个Segment，当线程占用了一个Segment时,其他线程可以访问其他段的数据。
Segment:可重入锁，继承至ReentrantLock,也可以称之为桶。
但是，仅使用segment[]是不够的，如何确保数据能够均匀的分布到Segment中，也是解决性能问题的关键，例如:所有的数据经过hash算法后恰好都分配到了同一个segment中，此时的效率和未使用分段技术是一样的，那么，如何确保数据能够均匀的分布到Segment[]中呢?
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);
}ConcurrntHashMao中实现了一个变种的Wang/Jenkins哈希算法来保证数据的均匀分布，Wang/Jenkins哈希算法能够实现散列的均匀分布，又出于对Wang/Jenkins哈希算法的雪崩性和可逆性的权衡，最终进行了一些变化。
关于Segment的长度为什么需要维护成2的乘次方并且还是固定长度的，我们可以先回忆一下HashMap中对table[]为什么会维护它的长度为2的乘次方呢？一方面是因为可以通过一些位运算使得数组在扩容时能够提高性能，另一方面是因为可以进行巧妙的取模运算来提高性能。同样的原因，为了，JDk1.7中的concurrent的实现将这个特性延续下来。而为什么将segment的长度固定是因为，创建segment需要耗费的性能是非常大的，所以选择一个固定的长度来表示segment,在进行扩容时，实际上是对由HashEntity组成的table进行扩容。
JDK1.7版本下，ConcurrentHashMap的结构图如下所示:
在图中有一个Segment数组，该数组的主要作用便是用来实现
构造方法:
/**
* initialCapacity(初始容量)， loadFactor(增长因子)
* concurrencyLevel(并发等级)来初始化segmentShift（段偏移量）、segmentMask（段掩码）和segment数组。
*/
public ConcurrentHashMap(int initialCapacity,
float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();
if (concurrencyLevel > MAX_SEGMENTS)
//最大的并发等级不能超过MAX_SEGMENTS 1<<16(也就是1的二进制向左移16位,65535)
concurrencyLevel = MAX_SEGMENTS;
int sshift = 0;
int ssize = 1;
while (ssize < concurrencyLevel) {
++sshift;
// 如果你传入的是15 就是向上取2的4次方倍 也就是16.
ssize <<= 1;
}
/**
* segmentShift和segmentMask在定位segment使用，segmentShift = 32 - ssize向左移位的次数，
* segmentMask = ssize - 1。ssize的最大长度是65536，对应的 segmentShift最大值为16，segmentMask最大值是65535，
* 对应的二进制16位全为1；
*/
this.segmentShift = 32 - sshift;
this.segmentMask = ssize - 1; //4
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
int c = initialCapacity / ssize;
if (c * ssize < initialCapacity)
++c;
int cap = MIN_SEGMENT_TABLE_CAPACITY;
while (cap < c)
cap <<= 1;
Segment<K,V> s0 =
new Segment<K,V>(loadFactor, (int)(cap * loadFactor),
(HashEntry<K,V>[])new HashEntry[cap]);//5
Segment<K,V>[] ss = (Segment<K,V>[])new Segment[ssize]; //6
UNSAFE.putOrderedObject(ss, SBASE, s0);
this.segments = ss;
}
get操作:
Segment的get操作实现非常简单和高效。先经过一次再哈希，然后使用这个哈希值通过哈希运算定位到segment，再通过哈希算法定位到元素，代码如下：
public V get(Object key) {
int hash = hash(key.hashCode());
return segmentFor(hash).get(key, hash);
}get操作的高效之处在于整个get过程不需要加锁，除非读到的值是空的才会加锁重读，我们知道HashTable容器的get方法是需要加锁的，那么ConcurrentHashMap的get操作是如何做到不加锁的呢？原因是它的get方法里将要使用的共享变量都定义成volatile，如用于统计当前Segement大小的count字段和用于存储值的HashEntry的value。定义成volatile的变量，能够在线程之间保持可见性，能够被多线程同时读，并且保证不会读到过期的值，但是只能被单线程写（有一种情况可以被多线程写，就是写入的值不依赖于原值），在get操作里只需要读不需要写共享变量count和value，所以可以不用加锁。之所以不会读到过期的值，是根据java内存模型的happen before原则，对volatile字段的写入操作先于读操作，即使两个线程同时修改和获取volatile变量，get操作也能拿到最新的值，这是用volatile替换锁的经典应用场景。
为什么ConcurrentHashMap中的get()不需要加锁?
HashEntry源码:
static final class HashEntry<K,V> {
final int hash;
final K key;
volatile V value;
volatile HashEntry<K,V> next;关于HashEntry的属性不是不可变的final型就是volatile修饰的， volatile关键字保证了多线程读取的时候一定是最新值。所以,在进行get()操作的时候可以不用进行加锁操作。
在定位元素的代码里我们可以发现定位HashEntry和定位Segment的哈希算法虽然一样，都与数组的长度减去一相与，但是相与的值不一样，定位Segment使用的是元素的hashcode通过再哈希后得到的值的高位，而定位HashEntry直接使用的是再哈希后的值。其目的是避免两次哈希后的值一样，导致元素虽然在Segment里散列开了，但是却没有在HashEntry里散列开。
hash >>> segmentShift) & segmentMask//定位Segment所使用的hash算法
int index = hash & (tab.length - 1);// 定位HashEntry所使用的hash算法Put操作
public V put(K key, V value) {
Segment<K,V> s;
if (value == null)
throw new NullPointerException();
int hash = hash(key);
int j = (hash >>> segmentShift) & segmentMask;
if ((s = (Segment<K,V>)UNSAFE.getObject
(segments, (j << SSHIFT) + SBASE)) == null)
s = ensureSegment(j);
return s.put(key, hash, value, false);
}
1.判断值是否为null
2.计算hash值
3.定位segment 如果不存在，则创建
4.调用segment的put方法
再来看看Segment的put方法
final V put(K key, int hash, V value, boolean onlyIfAbsent) {
HashEntry<K,V> node = tryLock() ? null :
scanAndLockForPut(key, hash, value); //获取锁，保证线程安全
V oldValue;
try {
HashEntry<K,V>[] tab = table; //获取hash表
int index = (tab.length - 1) & hash; //定位
HashEntry<K,V> first = entryAt(tab, index); //获得具体的HashEntity
for (HashEntry<K,V> e = first;;) { //遍历HashEntity链表，如果key存在 在判断传入的onlyIfAbsent的值再决定覆盖旧值
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方法里需要对共享变量进行写入操作，所以为了线程安全，在操作共享变量时必须得加锁。Put方法首先定位到Segment，然后在Segment里进行插入操作。插入操作需要经历两个步骤，第一步判断是否需要对Segment里的HashEntry数组进行扩容，第二步定位添加元素的位置然后放在HashEntry数组里。
是否需要扩容。在插入元素前会先判断Segment里的HashEntry数组是否超过容量（threshold），如果超过阀值，数组进行扩容。值得一提的是，Segment的扩容判断比HashMap更恰当，因为HashMap是在插入元素后判断元素是否已经到达容量的，如果到达了就进行扩容，但是很有可能扩容之后没有新元素插入，这时HashMap就进行了一次无效的扩容。
如何扩容。扩容的时候首先会创建一个两倍于原容量的数组，然后将原数组里的元素进行再hash后插入到新的数组里。为了高效ConcurrentHashMap不会对整个容器进行扩容，而只对某个segment进行扩容。
size操作
如果我们要统计整个ConcurrentHashMap里元素的大小，就必须统计所有Segment里元素的大小后求和。Segment里的全局变量count是一个volatile变量，那么在多线程场景下，我们是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢？不是的，虽然相加时可以获取每个Segment的count的最新值，但是拿到之后可能累加前使用的count发生了变化，那么统计结果就不准了。所以最安全的做法，是在统计size的时候把所有Segment的put，remove和clean方法全部锁住，但是这种做法显然非常低效。 因为在累加count操作过程中，之前累加过的count发生变化的几率非常小，所以ConcurrentHashMap的做法是先尝试2次通过不锁住Segment的方式来统计各个Segment大小，如果统计的过程中，容器的count发生了变化，则再采用加锁的方式来统计所有Segment的大小。
那么ConcurrentHashMap是如何判断在统计的时候容器是否发生了变化呢？使用modCount变量，在put , remove和clean方法里操作元素前都会将变量modCount进行加1，那么在统计size前后比较modCount是否发生变化，从而得知容器的大小是否发生变化。
514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
