《深刻浅出 Java Concurrency》—并发容器 ConcurrentMap

（转自：http://blog.csdn.net/fg2006/article/details/6404226）

在JDK 1.4如下只有Vector和Hashtable是线程安全的集合（也称并发容器，Collections.synchronized*系列也能够看做是线程安全的实现）。从JDK 5开始增长了线程安全的Map接口ConcurrentMap和线程安全的队列BlockingQueue（尽管Queue也是同时期引入的新的集合，可是规范并无规定必定是线程安全的，事实上一些实现也不是线程安全的，好比PriorityQueue、ArrayDeque、LinkedList等，在Queue章节中会具体讨论这些队列的结构图和实现）。

 

在介绍ConcurrencyMap以前先来回顾下Map的体系结构。下图描述了Map的体系结构，其中蓝色字体的是JDK 5之后新增的并发容器。

针对上图有如下几点说明：

1. Hashtable是JDK 5以前Map惟一线程安全的内置实现（Collections.synchronizedMap不算）。特别说明的是Hashtable的t是小写的（不知道为啥），Hashtable继承的是Dictionary（Hashtable是其惟一公开的子类），并不继承AbstractMap或者HashMap。尽管Hashtable和HashMap的结构很是相似，可是他们之间并无多大联系。
2. ConcurrentHashMap是HashMap的线程安全版本，ConcurrentSkipListMap是TreeMap的线程安全版本。
3. 最终可用的线程安全版本Map实现是ConcurrentHashMap/ConcurrentSkipListMap/Hashtable/Properties四个，可是Hashtable是过期的类库，所以若是能够的应该尽量的使用ConcurrentHashMap和ConcurrentSkipListMap。

 

回到正题来，这个小节主要介绍ConcurrentHashMap的API以及应用，下一节才开始将原理和分析。

除了实现Map接口里面对象的方法外，ConcurrentHashMap还实现了ConcurrentMap里面的四个方法。

 

V putIfAbsent(K key,V value)

若是不存在key对应的值，则将value以key加入Map，不然返回key对应的旧值。这个等价于清单1 的操做：

清单1 putIfAbsent的等价操做

if (!map.containsKey(key)) 
   return map.put(key, value);
else
   return map.get(key);

在前面的章节中提到过，连续两个或多个原子操做的序列并不必定是原子操做。好比上面的操做即便在Hashtable中也不是原子操做。而putIfAbsent就是一个线程安全版本的操做的。

有些人喜欢用这种功能来实现单例模式，例如清单2。

清单2 一种单例模式的实现

package xylz.study.concurrency;

import Java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;

public class ConcurrentDemo1 {

    private static final ConcurrentMap<String, ConcurrentDemo1> map = new ConcurrentHashMap<String, ConcurrentDemo1>();
    private static ConcurrentDemo1 instance;
    public static ConcurrentDemo1 getInstance() {
        if (instance == null) {

            map.putIfAbsent("INSTANCE", new ConcurrentDemo1());

            instance = map.get("INSTANCE");
        }
        return instance;
    }

    private ConcurrentDemo1() {
    }

}

固然这里只是一个操做的例子，实际上在单例模式文章中有不少的实现和比较。清单2 在存在大量单例的状况下可能有用，实际状况下不多用于单例模式。可是这个方法避免了向Map中的同一个Key提交多个结果的可能，有时候在去掉重复记录上颇有用（若是记录的格式比较固定的话）。

 

boolean remove(Object key,Object value)

只有目前将键的条目映射到给定值时，才移除该键的条目。这等价于清单3 的操做。

清单3 remove(Object,Object)的等价操做

if (map.containsKey(key) && map.get(key).equals(value)) {
   map.remove(key);
   return true;
}
return false;

因为集合类一般比较的hashCode和equals方法，而这两个方法是在Object对象里面，所以两个对象若是hashCode一致，而且覆盖了equals方法后也一致，那么这两个对象在集合类里面就是“相同”的，无论是不是同一个对象或者同一类型的对象。也就是说只要key1.hashCode()==key2.hashCode() && key1.equals(key2)，那么key1和key2在集合类里面就认为是一致，哪怕他们的Class类型不一致也不要紧，因此在不少集合类里面容许经过Object来类型来比较（或者定位）。好比说Map尽管添加的时候只能经过制定的类型<K,V>，可是删除的时候却容许经过一个Object来操做，而没必要是K类型。

既然Map里面有一个remove(Object)方法，为何ConcurrentMap还须要remove(Object,Object)方法呢？这是由于尽管Map里面的key没有变化，可是value可能已经被其余线程修改了，若是修改后的值是咱们指望的，那么咱们就不能拿一个key来删除此值，尽管咱们的指望值是删除此key对于的旧值。

这种特性在原子操做章节的AtomicMarkableReference和AtomicStampedReference里面介绍过。

 

boolean replace(K key,V oldValue,V newValue)

只有目前将键的条目映射到给定值时，才替换该键的条目。这等价于清单4 的操做。

清单4 replace(K,V,V)的等价操做

if (map.containsKey(key) && map.get(key).equals(oldValue)) {
   map.put(key, newValue);
   return true;
}
return false;

 

V replace(K key,V value)

只有当前键存在的时候更新此键对于的值。这等价于清单5 的操做。

清单5 replace(K,V)的等价操做

if (map.containsKey(key)) {
   return map.put(key, value);
}
return null;

replace(K,V,V)相比replace(K,V)而言，就是增长了匹配oldValue的操做。

 

其实这4个扩展方法，是ConcurrentMap附送的四个操做，其实咱们更关心的是Map自己的操做。固然若是没有这4个方法，要完成相似的功能咱们可能须要额外的锁，因此有总比没有要好。好比清单6，若是没有putIfAbsent内置的方法，咱们若是要完成此操做就须要彻底锁住整个Map，这样就大大下降了ConcurrentMap的并发性。这在下一节中有详细的分析和讨论。

清单6 putIfAbsent的外部实现

public V putIfAbsent(K key, V value) {
    synchronized (map) {
        if (!map.containsKey(key)) return map.put(key, value);
        return map.get(key);
    }
}

 

part2

 

原本想比较全面和深刻的谈谈ConcurrentHashMap的，发现网上有不少对HashMap和ConcurrentHashMap分析的文章，所以本小节尽量的分析其中的细节，少一点理论的东西，多谈谈内部设计的原理和思想。

要谈ConcurrentHashMap的构造，就不得不谈HashMap的构造，所以先从HashMap开始简单介绍。

 

HashMap原理

咱们从头开始设想。要将对象存放在一块儿，如何设计这个容器。目前只有两条路能够走，一种是采用分格技术，每个对象存放于一个格子中，这样经过对格子的编号就能取到或者遍历对象；另外一种技术就是采用串联的方式，将各个对象串联起来，这须要各个对象至少带有下一个对象的索引（或者指针）。显然第一种就是数组的概念，第二种就是链表的概念。全部的容器的实现其实都是基于这两种方式的，无论是数组仍是链表，或者两者俱有。HashMap采用的就是数组的方式。

有了存取对象的容器后还须要如下两个条件才能完成Map所须要的条件。

• 可以快速定位元素：Map的需求就是可以根据一个查询条件快速获得须要的结果，因此这个过程须要的就是尽量的快。
• 可以自动扩充容量：显然对于容器而然，不须要人工的去控制容器的容量是最好的，这样对于外部使用者来讲越少知道底部细节越好，不只使用方便，也越安全。

首先条件1，快速定位元素。快速定位元素属于算法和数据结构的范畴，一般状况下哈希（Hash）算法是一种简单可行的算法。所谓哈希算法，是将任意长度的二进制值映射为固定长度的较小二进制值。常见的MD2,MD4,MD5，SHA-1等都属于Hash算法的范畴。具体的算法原理和介绍能够参考相应的算法和数据结构的书籍，可是这里特别提醒一句，因为将一个较大的集合映射到一个较小的集合上，因此必然就存在多个元素映射到同一个元素上的结果，这个叫“碰撞”，后面会用到此知识，暂且不表。

条件2，若是知足了条件1，一个元素映射到了某个位置，如今一旦扩充了容量，也就意味着元素映射的位置须要变化。由于对于Hash算法来讲，调整了映射的小集合，那么原来映射的路径确定就不复存在，那么就须要对现有从新计算映射路径，也就是所谓的rehash过程。

好了有了上面的理论知识后来看HashMap是如何实现的。

在HashMap中首先由一个对象数组table是不可避免的，修饰符transient只是表示序列号的时候不被存储而已。size描述的是Map中元素的大小，threshold描述的是达到指定元素个数后须要扩容，loadFactor是扩容因子(loadFactor>0)，也就是计算threshold的。那么元素的容量就是table.length，也就是数组的大小。换句话说，若是存取的元素大小达到了整个容量(table.length)的loadFactor倍（也就是table.length*loadFactor个），那么就须要扩充容量了。在HashMap中每次扩容就是将扩大数组的一倍，使数组大小为原来的两倍。

 

而后接下来看如何将一个元素映射到数组table中。显然要映射的key是一个无尽的超大集合，而table是一个较小的有限集合，那么一种方式就是将key编码后的hashCode值取模映射到table上，这样看起来不错。可是在Java中采用了一种更高效的办法。因为与(&)是比取模(%)更高效的操做，所以Java中采用hash值与数组大小-1后取与来肯定数组索引的。为何这样作是更有效的？参考资料7对这一块进行很是详细的分析，这篇文章的做者很是认真，也很是仔细的分析了里面包含的思想。

清单1 indexFor片断

static int indexFor(int h, int length) {
    return h & (length-1);
}

前面说明，既然是大集合映射到小集合上，那么就必然存在“碰撞”，也就是不一样的key映射到了相同的元素上。那么HashMap是怎么解决这个问题的？

在HashMap中采用了下面方式，解决了此问题。

1. 同一个索引的数组元素组成一个链表，查找容许时循环链表找到须要的元素。
2. 尽量的将元素均匀的分布在数组上。

对于问题1，HashMap采用了上图的一种数据结构。table中每个元素是一个Map.Entry，其中Entry包含了四个数据，key,value,hash,next。key和value是存储的数据；hash是元素key的Hash后的表现形式（最终要映射到数组上），这里链表上全部元素的hash通过清单1 的indexFor后将获得相同的数组索引；next是指向下一个元素的索引，同一个链表上的元素就是经过next串联起来的。

再来看问题2 尽量的将元素均匀的分布在数组上这个问题是怎么解决的。首先清单2 是将key的hashCode通过一系列的变换，使之更符合小数据集合的散列模型。

清单2 hashCode的二次散列

static int hash(int h) {
    // This function ensures that hashCodes that differ only by
    // constant multiples at each bit position have a bounded
    // number of collisions (approximately 8 at default load factor).
    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

至于清单2 为何这样散列我没有找到依据，也没有什么好的参考资料。参考资料1 分析了此过程，认为是一种比较有效的方式，有兴趣的能够研究下。

第二点就是在清单1 的描述中，尽量的与数组的长度减1的数与操做，使之分布均匀。这在参考资料7 中有介绍。

第三点就是构造数组时数组的长度是2的倍数。清单3 反映了这个过程。为何要是2的倍数？在参考资料7 中分析说是使元素尽量的分布均匀。

清单3 HashMap 构造数组

// Find a power of 2 >= initialCapacity
int capacity = 1;
while (capacity < initialCapacity)
    capacity <<= 1;

this.loadFactor = loadFactor;
threshold = (int)(capacity * loadFactor);
table = new Entry[capacity];

另外loadFactor的默认值0.75和capacity的默认值16是通过大量的统计分析得出的，好久之前我见过相关的数据分析，如今找不到了，有兴趣的能够查询相关资料。这里再也不叙述了。

有了上述原理后再来分析HashMap的各类方法就不是什么问题的。

清单4 HashMap的get操做

public V get(Object key) {
    if (key == null)
        return getForNullKey();
    int hash = hash(key.hashCode());
    for (Entry<K,V> e = table[indexFor(hash, table.length)];
         e != null;
         e = e.next) {
        Object k;
        if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
            return e.value;
    }
    return null;
}

清单4 描述的是HashMap的get操做，在这个操做中首先判断key是否为空，由于为空的话老是映射到table的第0个元素上（能够看上面的清单2和清单1）。而后就须要查找table的索引。一旦找到对应的Map.Entry元素后就开始遍历此链表。因为不一样的hash可能映射到同一个table[index]上，而相同的key却同时映射到相同的hash上，因此一个key和Entry对应的条件就是hash(key)==e.hash 而且key.equals(e.key)。从这里咱们看到，Object.hashCode()只是为了将相同的元素映射到相同的链表上（Map.Entry)，而Object.equals()才是比较两个元素是否相同的关键！这就是为何老是成对覆盖hashCode()和equals()的缘由。

清单5 HashMap的put操做

public V put(K key, V value) {
    if (key == null)
        return putForNullKey(value);
    int hash = hash(key.hashCode());
    int i = indexFor(hash, table.length);
    for (Entry<K,V> e = table[i]; e != null; e = e.next) {
        Object k;
        if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
            V oldValue = e.value;
            e.value = value;
            e.recordAccess(this);
            return oldValue;
        }
    }

    modCount++;
    addEntry(hash, key, value, i);
    return null;
}
void addEntry(int hash, K key, V value, int bucketIndex) {
    Entry<K,V> e = table[bucketIndex];
        table[bucketIndex] = new Entry<K,V>(hash, key, value, e);
        if (size++ >= threshold)
            resize(2 * table.length);
}

清单5 描述的是HashMap的put操做。对比get操做，能够发现，put其实是先查找，一旦找到key对应的Entry就直接修改Entry的value值，不然就增长一个元素。增长的元素是在链表的头部，也就是占据table中的元素，若是table中对应索引原来有元素的话就将整个链表添加到新增长的元素的后面。也就是说新增长的元素再次查找的话是优于在它以前添加的同一个链表上的元素。这里涉及到就是扩容，也就是一旦元素的个数达到了扩容因子规定的数量(threhold=table.length*loadFactor)，就将数组扩大一倍。

清单6 HashMap扩容过程

void resize(int newCapacity) {
    Entry[] oldTable = table;
    int oldCapacity = oldTable.length;
    if (oldCapacity == MAXIMUM_CAPACITY) {
        threshold = Integer.MAX_VALUE;
        return;
    }

    Entry[] newTable = new Entry[newCapacity];
    transfer(newTable);
    table = newTable;
    threshold = (int)(newCapacity * loadFactor);
}

void transfer(Entry[] newTable) {
    Entry[] src = table;
    int newCapacity = newTable.length;
    for (int j = 0; j < src.length; j++) {
        Entry<K,V> e = src[j];
        if (e != null) {
            src[j] = null;
            do {
                Entry<K,V> next = e.next;
                int i = indexFor(e.hash, newCapacity);
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            } while (e != null);
        }
    }
}

清单6 描述的是HashMap扩容的过程。能够看到扩充过程会致使元素数据的全部元素进行从新hash计算，这个过程也叫rehash。显然这是一个很是耗时的过程，不然扩容都会致使全部元素从新计算hash。所以尽量的选择合适的初始化大小是有效提升HashMap效率的关键。太大了会致使过多的浪费空间，过小了就可能会致使繁重的rehash过程。在这个过程当中loadFactor也能够考虑。

举个例子来讲，若是要存储1000个元素，采用默认扩容因子0.75，那么1024显然是不够的，由于1000>0.75*1024了，因此选择2048是必须的，显然浪费了1048个空间。若是肯定最多只有1000个元素，那么扩容因子为1，那么1024是不错的选择。另外须要强调的一点是扩容所以越大，从统计学角度讲意味着链表的长度就也大，也就是在查找元素的时候就须要更屡次的循环。因此凡事必然是一个平衡的过程。

这里可能有人要问题，一旦我将Map的容量扩大后（也就是数组的大小），这个容量还能减少么？好比说刚开始Map中可能有10000个元素，运行一旦时间之后Map的大小永远不会超过10个，那么Map的容量能减少到10个或者16个么？答案就是不能，这个capacity一旦扩大后就不能减少了，只能经过构造一个新的Map来控制capacity了。

 

HashMap的几个内部迭代器也是很是重要的，这里限于篇幅就再也不展开了，有兴趣的能够本身研究下。

Hashtable的原理和HashMap的原理几乎同样，因此就不讨论了。另外LinkedHashMap是在Map.Entry的基础上增长了before/after两个双向索引，用来将全部Map.Entry串联起来，这样就能够遍历或者作LRU Cache等。这里也再也不展开讨论了。

 

memcached 内部数据结构就是采用了HashMap相似的思想来实现的，有兴趣的能够参考资料8,9，10。

 

为了避免使这篇文章过长，所以将ConcurrentHashMap的原理放到下篇讲。须要说明的是，尽管ConcurrentHashMap与HashMap的名称有些渊源，并且实现原理有些类似，可是为了更好的支持并发，ConcurrentHashMap在内部也有一些比较大的调整，这个在下篇会具体介绍。

 

 

参考资料：

1. HashMap hash方法分析
2. 经过分析 JDK 源代码研究 Hash 存储机制
3. Java 理论与实践: 哈希
4. Java 理论与实践: 构建一个更好的 HashMap
5. jdk1.6 ConcurrentHashMap
6. ConcurrentHashMap之实现细节
7. 深刻理解HashMap
8. memcached-数据结构
9. memcached存储管理 数据结构
10. memcached

part3

 

ConcurrentHashMap原理

 

在读写锁章节部分介绍过一种是用读写锁实现Map的方法。此种方法看起来能够实现Map响应的功能，并且吞吐量也应该不错。可是经过前面对读写锁原理的分析后知道，读写锁的适合场景是读操做>>写操做，也就是读操做应该占据大部分操做，另外读写锁存在一个很严重的问题是读写操做不能同时发生。要想解决读写同时进行问题（至少不一样元素的读写分离），那么就只能将锁拆分，不一样的元素拥有不一样的锁，这种技术就是“锁分离”技术。

默认状况下ConcurrentHashMap是用了16个相似HashMap 的结构，其中每个HashMap拥有一个独占锁。也就是说最终的效果就是经过某种Hash算法，将任何一个元素均匀的映射到某个HashMap的Map.Entry上面，而对某个一个元素的操做就集中在其分布的HashMap上，与其它HashMap无关。这样就支持最多16个并发的写操做。

 

 

上图就是ConcurrentHashMap的类图。参考上面的说明和HashMap的原理分析，能够看到ConcurrentHashMap将整个对象列表分为segmentMask+1个片断（Segment）。其中每个片断是一个相似于HashMap的结构，它有一个HashEntry的数组，数组的每一项又是一个链表，经过HashEntry的next引用串联起来。

这个类图上面的数据结构的定义很是有学问，接下来会一个个有针对性的分析。

首先如何从ConcurrentHashMap定位到HashEntry。在HashMap的原理分析部分说过，对于一个Hash的数据结构来讲，为了减小浪费的空间和快速定位数据，那么就须要数据在Hash上的分布比较均匀。对于一次Map的查找来讲，首先就须要定位到Segment，而后从过Segment定位到HashEntry链表，最后才是经过遍历链表获得须要的元素。

在不讨论并发的前提下先来讨论如何定位到HashEntry的。在ConcurrentHashMap中是经过hash(key.hashCode())和segmentFor(hash)来获得Segment的。清单1 描述了如何定位Segment的过程。其中hash(int)是将key的hashCode进行二次编码，使之可以在segmentMask+1个Segment上均匀分布（默认是16个）。能够看到的是这里和HashMap仍是有点不一样的，这里采用的算法叫Wang/Jenkins hash，有兴趣的能够参考资料1和参考资料2。总之它的目的就是使元素可以均匀的分布在不一样的Segment上，这样才可以支持最多segmentMask+1个并发，这里segmentMask+1是segments的大小。

清单1 定位Segment

private static int hash(int h) {
    // Spread bits to regularize both segment and index locations,
    // using variant of single-word Wang/Jenkins hash.
    h += (h <<  15) ^ 0xffffcd7d;
    h ^= (h >>> 10);
    h += (h <<   3);
    h ^= (h >>>  6);
    h += (h <<   2) + (h << 14);
    return h ^ (h >>> 16);
}
final Segment<K,V> segmentFor(int hash) {
    return segments[(hash >>> segmentShift) & segmentMask];
}

显然在不可以对Segment扩容的状况下，segments的大小就应该是固定的。因此在ConcurrentHashMap中segments/segmentMask/segmentShift都是常量，一旦初始化后就不能被再次修改，其中segmentShift是查找Segment的一个常量偏移量。

有了Segment之后再定位HashEntry就和HashMap中定位HashEntry同样了，先将hash值与Segment中HashEntry的大小减1进行与操做定位到HashEntry链表，而后遍历链表就能够完成相应的操做了。

 

可以定位元素之后ConcurrentHashMap就已经具备了HashMap的功能了，如今要解决的就是如何并发的问题。要解决并发问题，加锁是必不可免的。再回头看Segment的类图，能够看到Segment除了有一个volatile类型的元素大小count外，Segment仍是集成自ReentrantLock的。另外在前面的原子操做和锁机制中介绍过，要想最大限度的支持并发，那么可以利用的思路就是尽可能读操做不加锁，写操做不加锁。若是是读操做不加锁，写操做加锁，对于竞争资源来讲就须要定义为volatile类型的。volatile类型可以保证happens-before法则，因此volatile可以近似保证正确性的状况下最大程度的下降加锁带来的影响，同时还与写操做的锁不产生冲突。

同时为了防止在遍历HashEntry的时候被破坏，那么对于HashEntry的数据结构来讲，除了value以外其余属性就应该是常量，不然不可避免的会获得ConcurrentModificationException。这就是为何HashEntry数据结构中key,hash,next是常量的缘由(final类型）。

有了上面的分析和条件后再来看Segment的get/put/remove就容易多了。

get操做

 

清单2 Segment定位元素

V get(Object key, int hash) {
    if (count != 0) { // read-volatile
        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;
}
HashEntry<K,V> getFirst(int hash) {
    HashEntry<K,V>[] tab = table;
    return tab[hash & (tab.length - 1)];
}

V readValueUnderLock(HashEntry<K,V> e) {
    lock();
    try {
        return e.value;
    } finally {
        unlock();
    }
}

清单2 描述的是Segment如何定位元素。首先判断Segment的大小count>0，Segment的大小描述的是HashEntry不为空(key不为空)的个数。若是Segment中存在元素那么就经过getFirst定位到指定的HashEntry链表的头节点上，而后遍历此节点，一旦找到key对应的元素后就返回其对应的值。可是在清单2 中能够看到拿到HashEntry的value后还进行了一次判断操做，若是为空还须要加锁再读取一次（readValueUnderLock）。为何会有这样的操做？尽管ConcurrentHashMap不容许将value为null的值加入，但如今仍然可以读到一个为空的value就意味着此值对当前线程还不可见（这是由于HashEntry尚未彻底构造完成就赋值致使的，后面还会谈到此机制）。

 

put操做

 

清单3 描述的是Segment的put操做。首先就须要加锁了，修改一个竞争资源确定是要加锁的，这个毫无疑问。须要说明的是Segment集成的是ReentrantLock，因此这里加的锁也就是独占锁，也就是说同一个Segment在同一时刻只有能一个put操做。

接下来来就是检查是否须要扩容，这和HashMap同样，若是须要的话就扩大一倍，同时进行rehash操做。

查找元素就和get操做是同样的，获得元素就直接修改其值就行了。这里onlyIfAbsent只是为了实现ConcurrentMap的putIfAbsent操做而已。须要说明如下几点：

• 若是找到key对于的HashEntry后直接修改就行了，若是找不到那么就须要构造一个新的HashEntry出来加到hash对于的HashEntry的头部，同时就的头部就加到新的头部后面。这是由于HashEntry的next是final类型的，因此只能修改头节点才能加元素加入链表中。
• 若是增长了新的操做后，就须要将count+1写回去。前面说过count是volatile类型，而读取操做没有加锁，因此只能把元素真正写回Segment中的时候才能修改count值，这个要放到整个操做的最后。
• 在将新的HashEntry写入table中时是经过构造函数来设置value值的，这意味对table的赋值可能在设置value以前，也就是说获得了一个半构造完的HashEntry。这就是重排序可能引发的问题。因此在读取操做中，一旦读到了一个value为空的value是就须要加锁从新读取一次。为何要加锁？加锁意味着前一个写操做的锁释放，也就是前一个锁的数据已经完成写完了了，根据happens-before法则，前一个写操做的结果对当前读线程就可见了。固然在JDK 6.0之后不必定存在此问题。
• 在Segment中table变量是volatile类型，屡次读取volatile类型的开销要不非volatile开销要大，并且编译器也没法优化，因此在put操做中首先创建一个临时变量tab指向table，屡次读写tab的效率要比volatile类型的table要高，JVM也可以对此进行优化。

清单3 Segment的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();
    }
}

 

remove 操做

 

清单4 描述了Segment删除一个元素的过程。同put同样，remove也须要加锁，这是由于对table可能会有变动。因为HashEntry的next节点是final类型的，因此一旦删除链表中间一个元素，就须要将删除以前或者以后的元素从新加入新的链表。而Segment采用的是将删除元素以前的元素一个个从新加入删除以后的元素以前（也就是链表头结点）来完成新链表的构造。

 

清单4 Segment的remove操做

V remove(Object key, int hash, Object value) {
    lock();
    try {
        int c = count - 1;
        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 = null;
        if (e != null) {
            V v = e.value;
            if (value == null || value.equals(v)) {
                oldValue = v;
                // All entries following removed node can stay
                // in list, but all preceding ones need to be
                // cloned.
                ++modCount;
                HashEntry<K,V> newFirst = e.next;
                for (HashEntry<K,V> p = first; p != e; p = p.next)
                    newFirst = new HashEntry<K,V>(p.key, p.hash,
                                                  newFirst, p.value);
                tab[index] = newFirst;
                count = c; // write-volatile
            }
        }
        return oldValue;
    } finally {
        unlock();
    }
}

下面的示意图描述了如何删除一个已经存在的元素的。假设咱们要删除B3元素。首先定位到B3所在的Segment，而后再定位到Segment的table中的B1元素，也就是Bx所在的链表。而后遍历链表找到B3，找到以后就从头结点B1开始构建新的节点B1（蓝色）加到B4的前面，继续B1后面的节点B2构造B2（蓝色），加到由蓝色的B1和B4构成的新的链表。继续下去，直到遇到B3后终止，这样就构造出来一个新的链表B2（蓝色）->B1（蓝色）->B4->B5，而后将此链表的头结点B2（蓝色）设置到Segment的table中。这样就完成了元素B3的删除操做。须要说明的是，尽管就的链表仍然存在(B1->B2->B3->B4->B5)，可是因为没有引用指向此链表，因此此链表中无引用的（B1->B2->B3）最终会被GC回收掉。这样作的一个好处是，若是某个读操做在删除时已经定位到了旧的链表上，那么此操做仍然将能读到数据，只不过读取到的是旧数据而已，这在多线程里面是没有问题的。

除了对单个元素操做外，还有对所有的Segment的操做，好比size()操做等。

size操做

size操做涉及到统计全部Segment的大小，这样就会遍历全部的Segment，若是每次加锁就会致使整个Map都被锁住了，任何须要锁的操做都将没法进行。这里用到了一个比较巧妙的方案解决此问题。

在Segment中有一个变量modCount，用来记录Segment结构变动的次数，结构变动包括增长元素和删除元素，每增长一个元素操做就+1，每进行一次删除操做+1，每进行一次清空操做(clear)就+1。也就是说每次涉及到元素个数变动的操做modCount都会+1，并且一直是增大的，不会减少。

遍历两次ConcurrentHashMap中的segments，每次遍历是记录每个Segment的modCount，比较两次遍历的modCount值的和是否相同，若是相同就返回在遍历过程当中获取的Segment的count的和，也就是全部元素的个数。若是不相同就重复再作一次。重复一次还不相同就将全部Segment锁住，一个一个的获取其大小(count)，最后将这些count加起来获得总的大小。固然了最后须要将锁一一释放。清单5 描述了这个过程。

这里有一个比较高级的话题是为何在读取modCount的时候老是先要读取count一下。为何不是先读取modCount而后再读取count的呢？也就是说下面的两条语句可否交换下顺序？

sum += segments[i].count;

mcsum += mc[i] = segments[i].modCount;

答案是不能！为何？这是由于modCount老是在加锁的状况下才发生变化，因此不会发生多线程同时修改的状况，也就是不必时volatile类型。另外老是在count修改的状况下修改modCount，而count是一个volatile变量。因而这里就充分利用了volatile的特性。

根据happens-before法则，第（3）条：对volatile字段的写入操做happens-before于每个后续的同一个字段的读操做。也就是说一个操做C在volatile字段的写操做以后，那么volatile写操做以前的全部操做都对此操做C可见。因此修改modCount老是在修改count以前，也就是说若是读取到了一个count的值，那么在count变化以前的modCount也就可以读取到，换句话说就是若是看到了count值的变化，那么就必定看到了modCount值的变化。而若是上面两条语句交换下顺序就没法保证这个结果必定存在了。

在ConcurrentHashMap.containsValue中，能够看到每次遍历segments时都会执行int c = segments[i].count;，可是接下来的语句中又不用此变量c，尽管如此JVM仍然不能将此语句优化掉，由于这是一个volatile字段的读取操做，它保证了一些列操做的happens-before顺序，因此是相当重要的。在这里能够看到：

ConcurrentHashMap将volatile发挥到了极致！

 

另外isEmpty操做于size操做相似，再也不累述。

清单5 ConcurrentHashMap的size操做

public int size() {
    final Segment<K,V>[] segments = this.segments;
    long sum = 0;
    long check = 0;
    int[] mc = new int[segments.length];
    // Try a few times to get accurate count. On failure due to
    // continuous async changes in table, resort to locking.
    for (int k = 0; k < RETRIES_BEFORE_LOCK; ++k) {
        check = 0;
        sum = 0;
        int mcsum = 0;
        for (int i = 0; i < segments.length; ++i) {
            sum += segments[i].count;
            mcsum += mc[i] = segments[i].modCount;
        }
        if (mcsum != 0) {
            for (int i = 0; i < segments.length; ++i) {
                check += segments[i].count;
                if (mc[i] != segments[i].modCount) {
                    check = -1; // force retry
                    break;
                }
            }
        }
        if (check == sum)
            break;
    }
    if (check != sum) { // Resort to locking all segments
        sum = 0;
        for (int i = 0; i < segments.length; ++i)
            segments[i].lock();
        for (int i = 0; i < segments.length; ++i)
            sum += segments[i].count;
        for (int i = 0; i < segments.length; ++i)
            segments[i].unlock();
    }
    if (sum > Integer.MAX_VALUE)
        return Integer.MAX_VALUE;
    else
        return (int)sum;
}

 

ConcurrentSkipListMap/Set

原本打算介绍下ConcurrentSkipListMap的，结果打开源码一看，完全放弃了。那里面的数据结构和算法我估计研究一周也未必可以彻底弄懂。好久之前我看TreeMap的时候就头大，想一想那些复杂的“红黑二叉树”我头都大了。这些都归咎于从前没有好好学习《数据结构和算法》，如今再回头看这些复杂的算法感受很是头疼，为了减小脑细胞的死亡，暂且仍是不要惹这些“玩意儿”。有兴趣的能够看看参考资料4 中对TreeMap的介绍。

 

参考资料：

1. Hash this
2. Single-word Wang/Jenkins Hash in ConcurrentHashMap
3. 指令重排序与happens-before法则
4. 经过分析 JDK 源代码研究 TreeMap 红黑树算法实现