浅谈ConcurrentHashMap实现原理
我们都知道HashTable是线程安全的类，因为使用了Synchronized来锁整张Hash表来实现线程安全，让线程独占；
ConcurrentHashMap的锁分离技术就是用多个锁来控制对Hash表的不同部分进行修改，因为我可能只需要对一小块部分进行操作，而如果锁整张表开销太大了，其内部实现就是用Semgent来控制的，每个Semgent都是一个小的HashTable，他们有自己的锁；
然后有些方法需要访问整个表，比如Size，ContainsValue肯定是要访问整个表的数据，这个时候就需要锁整张表，ConcurrentHashMap就会按顺序锁定每个Segment，操作完毕之后再按顺序释放每个Segment，按顺序是为了防止出现死锁；
引用一张图片解释ConcurrentHashMap的结构：
可以看出就是在HashMap的基础上多了一个数组(暂且这样理解)，数组的每个元素就是Segment；Segment<K,V> extends ReentrantLock implements Serializable；
ConcurrentHashMap的构造函数：
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; int c = initialCapacity / ssize; if (c * ssize < initialCapacity) ++c; int cap = MIN_SEGMENT_TABLE_CAPACITY; while (cap < c) cap <<= 1; // create segments and segments[0] 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; }
ConcurrentHahsMap进行Put操作的时候，对Key需要进行3次Hash运算才能确定最终的位置：hash1(key) -> x1(得到一个值)；hash2(x1) -> x2(确定Segment位置，第二次hash是为了减少hash碰撞)；hash3(x2) -> x3(确定元素放入哪个HashEntry)；这里只是用比较好理解的白话说，下面会说原理；
ConcurrentHashMap中主要实体类就是三个：ConcurrentHashMap(整个Hash表),Segment(桶)，HashEntry(节点)；
static final class HashEntry<K,V> { final K key; final int hash; volatile V value; final HashEntry<K,V> next; }
可以看出，除了value不是final，其next属性都是final，说明不能从hash链的中间或尾部添加或删除节点；对于Put操作，可以一律将元素添加到hash链的头部，而对于remove操作，从中间删除一个节点，将该节点的前面所有节点复制一份并指向删除节点的下一节点；这会产生两条Hash链，这也是为了保证多线程访问的同步性；将value设置成volatile，这样避免了加锁；因为一个线程在执行get，另一个线程在执行remove，remove还没有执行完的时候，get能看到remove之前的值，如下图：
下面说说Segment的数据结构：
static final class Segment<K,V> extends ReentrantLock implements Serializable { /** * count用来统计该段数据的个数，它是volatile，如增加/删除节点，都要写count值，每次读取操作开始都要读取count的值。 */ transient volatileint count; /** * modCount统计段结构改变的次数，主要是为了检测对多个段进行遍历过程中某个段是否发生改变 */ transient int modCount; /** * rehash界限值 */ transient int threshold; /** * 就是上面的HashEntry */ transient volatile HashEntry<K,V>[] table; /** * 负载因子 */ final float loadFactor; }
ConcurrentHashMap的get方法是直接调用Segment的get方法：
public V get(Object key) { int hash = hash(key); // throws NullPointerException if key null return segmentFor(hash).get(key, hash); }
V get(Object key, int hash) { if (count != 0) { // read-volatile 当前桶的数据个数是否为0 HashEntry<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; }
V readValueUnderLock(HashEntry<K,V> e) { lock(); try { return e.value; } finally { unlock(); } }
get方法是不需要加锁的，因为上面已经看到了count和HashEntry都是volatile；
源码中增加value可能为null的情况，是为了保险起见，当节点正在发生改变而又未锁定时就可能为空，而HashEntry中的value不是final的，所以个人认为是为了加此判断；
如用于统计当前Segement大小的count字段和用于存储值的HashEntry的value。定义成volatile的变量，能够在线程之间保持可见性，能够被多线程同时读，并且保证不会读到过期的值，但是只能被单线程写（有一种情况可以被多线程写，就是写入的值不依赖于原值），在get操作里只需要读不需要写共享变量count和value，所以可以不用加锁。之所以不会读到过期的值，是根据java内存模型的happen before原则，对volatile字段的写入操作先于读操作，即使两个线程同时修改和获取volatile变量，get操作也能拿到最新的值，这是用volatile替换锁的经典应用场景；
接下来看看Put操作：
V put(K key, int hash, V value, boolean onlyIfAbsent) { lock(); try { int c = count; if (c++ > threshold) // ensure capacity rehash(); HashEntry<K,V>[] tab = table; int index = hash & (tab.length - 1); HashEntry<K,V> first = tab[index]; HashEntry<K,V> e = first; while (e != null && (e.hash != hash || !key.equals(e.key))) e = e.next; V oldValue; if (e != null) { oldValue = e.value; if (!onlyIfAbsent) e.value = value; } else { oldValue = null; ++modCount; tab[index] = new HashEntry<K,V>(key, hash, first, value); count = c; // write-volatile } return oldValue; } finally { unlock(); } }
先上个锁，做个预判，容量+1的时候需不需要扩容，这个判断相比于HashMap做的非常精妙，因为HashMap是在增加元素之后才判断是否需要扩容，如果我扩容之后不增加元素，就白扩容了；
通过索引定位到HashEntry，判断如果不为空，替换节点的value，否则new一个Entry，将此Entry插入到链头，由构造函数得知，它的next则是first；
扩容默认也是会创建两倍容量的数组，进行计算将原数组的数据插入到新数组，ConcurrentHashMap不会对整个容器进行扩容，而只对某个segment进行扩容；
ConcurrentHashMap的size方法
需要统计所有segment的元素总和，为了不影响性能，它会先2次尝试不锁住segment来统计大小，如果统计的过程中count发生了变化，则会把所有的segment的put和remove方法全部锁住；通过modCount来协助判断容器是否发生变化；统计size前后判断modCount是否发生变化即可；
参考：http://www.cnblogs.com/ITtangtang/p/3948786.html
