ConcurrentHashMap解析

曾经研究过jkd1.5新特性，其中ConcurrentHashMap就是其中之一，其特点：效率比Hashtable高，并发性比hashmap好。结合了两者的特点。
   集合是编程中最常用的数据结构。而谈到并发，几乎总是离不开集合这类高级数据结构的支持。比如两个线程需要同时访问一个中间临界区（Queue），比如常会用缓存作为外部文件的副本（HashMap）。这篇文章主要分析jdk1.5的3种并发集合类型（concurrent，copyonright，queue）中的ConcurrentHashMap，让我们从原理上细致的了解它们，能够让我们在深度项目开发中获益非浅。

    在tiger之前，我们使用得最多的数据结构之一就是HashMap和Hashtable。大家都知道，HashMap中未进行同步考虑，而Hashtable则使用了synchronized，带来的直接影响就是可选择，我们可以在单线程时使用HashMap提高效率，而多线程时用Hashtable来保证安全。

    当我们享受着jdk带来的便利时同样承受它带来的不幸恶果。通过分析Hashtable就知道，synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，安全的背后是巨大的浪费 ，慧眼独具的DougLee立马拿出了解决方案----ConcurrentHashMap。

 

   ConcurrentHashMap和Hashtable主要区别就是围绕着锁的粒度以及如何锁。如图

左边便是Hashtable的实现方式---锁整个hash表；而右边则是ConcurrentHashMap的实现方式---锁桶（或段）。   ConcurrentHashMap将hash表分为16个桶（默认值），诸如get,put,remove等常用操作只锁当前需要用到的桶。试想，原来 只能一个线程进入，现在却能同时16个写线程进入（写线程才需要锁定，而读线程几乎不受限制，之后会提到），并发性的提升是显而易见的。

    更令人惊讶的是ConcurrentHashMap的读取并发，因为在读取的大多数时候都没有用到锁定，所以读取操作几乎是完全的并发操作，而写操作锁定的粒度又非常细，比起之前又更加快速（这一点在桶更多时表现得更明显些）。只有在求size等操作时才需要锁定整个表 。而在迭代时，ConcurrentHashMap使用了不同于传统集合的快速失败迭代器（见之前的文章《JAVA API备忘---集合》）的另一种迭代方式，我们称为弱一致迭代器。 在这种迭代方式中，当iterator被创建后集合再发生改变就不再是抛出 ConcurrentModificationException，取而代之的是在改变时new新的数据从而不影响原有的数 据，iterator完成后再将头指针替换为新的数据，这样iterator线程可以使用原来老的数据，而写线程也可以并发的完成改变，更重要的，这保证 了多个线程并发执行的连续性和扩展性，是性能提升的关键。

    接下来，让我们看看ConcurrentHashMap中的几个重要方法，心里知道了实现机制后，使用起来就更加有底气。

    ConcurrentHashMap中主要实体类就是三个：ConcurrentHashMap（整个Hash表）,Segment（桶），HashEntry（节点） ，对应上面的图可以看出之间的关系。

    get 方法（请注意，这里分析的方法都是针对桶的，因为ConcurrentHashMap的最大改进就是将粒度细化到了桶上），首先判断了当前桶的数据个数是 否为0，为0自然不可能get到什么，只有返回null，这样做避免了不必要的搜索，也用最小的代价避免出错。然后得到头节点（方法将在下面涉及）之后就 是根据hash和key逐个判断是否是指定的值，如果是并且值非空就说明找到了，直接返回；程序非常简单，但有一个令人困惑的地方，这句return readValueUnderLock(e) 到底是用来干什么的呢？研究它的代码，在锁定之后返回一个值。但这里已经有一句V v = e.value得到了节点的值，这句return readValueUnderLock(e)是否多此一举？事实上，这里完全是为了并发考虑的，这里当v为空时，可能是一个线程正在改变节点，而之前的 get操作都未进行锁定，根据bernstein条件，读后写或写后读都会引起数据的不一致，所以这里要对这个e重新上锁再读一遍，以保证得到的是正确值， 这里不得不佩服Doug Lee思维的严密性。整个get操作只有很少的情况会锁定，相对于之前的Hashtable，并发是不可避免的啊！

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
;
}

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

put 操作一上来就锁定了整个segment，这当然是为了并发的安全，修改数据是不能并发进行的 ，必须得有个判断是否超限的语句以确保容量不足时能够 rehash，而比较难懂的是这句int index = hash & (tab.length - 1)，原来segment里面才是真正的hashtable，即每个segment是一个传统意义上的hashtable ,如上图，从两者的结构就可以看出区别，这里就是找出需要的entry在table的哪一个位置，之后得到的entry就是这个链的第一个节点，如果e!=null，说明找到了，这是就要替换节点的值（onlyIfAbsent == false），否则，我们需要new一个entry，它的后继是first，而让tab[index]指向它，什么意思呢？实际上就是将这个新entry 插入到链头，剩下的就非常容易理解了。

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 操作非常类似put，但要注意一点区别，中间那个for循环是做什么用的呢？（*号标记）从代码来看，就是将定位之后的所有entry克隆并拼回前面去， 但有必要吗？每次删除一个元素就要将那之前的元素克隆一遍？这点其实是由entry的不变性来决定的，仔细观察entry定义，发现除了value，其他 所有属性都是用final来修饰的，这意味着在第一次设置了next域之后便不能再改变它，取而代之的是将它之前的节点全都克隆一次。至于entry为什么要设置为不变性，这跟不变性的访问不需要同步从而节省时间有关，关于不变性的更多内容，请参阅之前的文章《线程高级---线程的一些编程技巧》

    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();
        }
    }

static
 
final
 
class
 HashEntry<K,V> {
    final
 K key;
    final
 
int
 hash;
    volatile
 V value;
    final
 HashEntry<K,V> next;

    HashEntry(K key, int
 hash, HashEntry<K,V> next, V value) {
        this
.key = key;
        this
.hash = hash;
        this
.next = next;
        this
.value = value;
    }

　　@SuppressWarnings
(
"unchecked"
)
　　static
 
final
 <K,V> HashEntry<K,V>[] newArray(
int
 i) {
    　　return
 
new
 HashEntry[i];
　　}
}

 

 

 

Java并发编程之ConcurrentHashMap

 

 

ConcurrentHashMap

ConcurrentHashMap是一个线程安全的Hash Table，它的主要功能是提供了一组和HashTable功能相同但是线程安全的方法。ConcurrentHashMap可以做到读取数据不加锁，并且其内部的结构可以让其在进行写操作的时候能够将锁的粒度保持地尽量地小，不用对整个ConcurrentHashMap加锁。

ConcurrentHashMap的内部结构

ConcurrentHashMap为了提高本身的并发能力，在内部采用了一个叫做Segment的结构，一个Segment其实就是一个类Hash Table的结构，Segment内部维护了一个链表数组，我们用下面这一幅图来看下ConcurrentHashMap的内部结构：

从上面的结构我们可以了解到，ConcurrentHashMap定位一个元素的过程需要进行两次Hash操作，第一次Hash定位到Segment，第二次Hash定位到元素所在的链表的头部，因此，这一种结构的带来的副作用是Hash的过程要比普通的HashMap要长，但是带来的好处是写操作的时候可以只对元素所在的Segment进行加锁即可，不会影响到其他的Segment，这样，在最理想的情况下，ConcurrentHashMap可以最高同时支持Segment数量大小的写操作（刚好这些写操作都非常平均地分布在所有的Segment上），所以，通过这一种结构，ConcurrentHashMap的并发能力可以大大的提高。

Segment

我们再来具体了解一下Segment的数据结构：

 

static
 
final
 
class
 Segment<K,V> 
extends
 ReentrantLock 
implements
 Serializable {
    transient
 
volatile
 
int
 count;
    transient
 
int
 modCount;
    transient
 
int
 threshold;
    transient
 
volatile
 HashEntry<K,V>[] table;
    final
 
float
 loadFactor;
}

 

 

详细解释一下Segment里面的成员变量的意义：

• count：Segment中元素的数量
• modCount：对table的大小造成影响的操作的数量（比如put或者remove操作）
• threshold：阈值，Segment里面元素的数量超过这个值依旧就会对Segment进行扩容
• table：链表数组，数组中的每一个元素代表了一个链表的头部
• loadFactor：负载因子，用于确定threshold

HashEntry

Segment中的元素是以HashEntry的形式存放在链表数组中的，看一下HashEntry的结构：

 

static
 
final
 
class
 HashEntry<K,V> {
    final
 K key;
    final
 
int
 hash;
    volatile
 V value;
    final
 HashEntry<K,V> next;
}

 

可以看到HashEntry的一个特点，除了value以外，其他的几个变量都是final的，这样做是为了防止链表结构被破坏，出现ConcurrentModification的情况。

ConcurrentHashMap的初始化

下面我们来结合源代码来具体分析一下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
;
    }
    segmentShift = 32
 - sshift;
    segmentMask = ssize - 1
;
    this
.segments = Segment.newArray(ssize);

    if
 (initialCapacity > MAXIMUM_CAPACITY)
        initialCapacity = MAXIMUM_CAPACITY;
    int
 c = initialCapacity / ssize;
    if
 (c * ssize < initialCapacity)
        ++c;
    int
 cap = 
1
;
    while
 (cap < c)
        cap <<= 1
;

    for
 (
int
 i = 
0
; i < 
this
.segments.length; ++i)
        this
.segments[i] = 
new
 Segment<K,V>(cap, loadFactor);
}

 

CurrentHashMap的初始化一共有三个参数，一个initialCapacity，表示初始的容量，一个loadFactor，表示负载参数，最后一个是concurrentLevel，代表ConcurrentHashMap内部的Segment的数量，ConcurrentLevel一经指定，不可改变，后续如果ConcurrentHashMap的元素数量增加导致ConrruentHashMap需要扩容，ConcurrentHashMap不会增加Segment的数量，而只会增加Segment中链表数组的容量大小，这样的好处是扩容过程不需要对整个ConcurrentHashMap做rehash，而只需要对Segment里面的元素做一次rehash就可以了。

整个ConcurrentHashMap的初始化方法还是非常简单的，先是根据concurrentLevel来new出Segment，这里Segment的数量是不大于concurrentLevel的最大的2的指数，就是说Segment的数量永远是2的指数个，这样的好处是方便采用移位操作来进行hash，加快hash的过程。接下来就是根据intialCapacity确定Segment的容量的大小，每一个Segment的容量大小也是2的指数，同样使为了加快hash的过程。

这边需要特别注意一下两个变量，分别是segmentShift和segmentMask，这两个变量在后面将会起到很大的作用，假设构造函数确定了Segment的数量是2的n次方，那么segmentShift就等于32减去n，而segmentMask就等于2的n次方减一。

ConcurrentHashMap的get操作

前面提到过ConcurrentHashMap的get操作是不用加锁的，我们这里看一下其实现：

 

public
 V get(Object key) {
    int
 hash = hash(key.hashCode());
    return
 segmentFor(hash).get(key, hash);
}

 

看第三行，segmentFor这个函数用于确定操作应该在哪一个segment中进行，几乎对ConcurrentHashMap的所有操作都需要用到这个函数，我们看下这个函数的实现：

 

final
 Segment<K,V> segmentFor(
int
 hash) {
    return
 segments[(hash >>> segmentShift) & segmentMask];
}

 

这个函数用了位操作来确定Segment，根据传入的hash值向右无符号右移segmentShift位，然后和segmentMask进行与操作，结合我们之前说的segmentShift和segmentMask的值，就可以得出以下结论：假设Segment的数量是2的n次方，根据元素的hash值的高n位就可以确定元素到底在哪一个Segment中。

在确定了需要在哪一个segment中进行操作以后，接下来的事情就是调用对应的Segment的get方法：

 

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
;
}

 

先看第二行代码，这里对count进行了一次判断，其中count表示Segment中元素的数量，我们可以来看一下count的定义：

 

transient
 
volatile
 
int
 count;

 

可以看到count是volatile的，实际上这里里面利用了volatile的语义：

 

 写道

对volatile字段的写入操作happens-before于每一个后续的同一个字段的读操作。

因为实际上put、remove等操作也会更新count的值，所以当竞争发生的时候，volatile的语义可以保证写操作在读操作之前，也就保证了写操作对后续的读操作都是可见的，这样后面get的后续操作就可以拿到完整的元素内容。

然后，在第三行，调用了getFirst()来取得链表的头部：

 

HashEntry<K,V> getFirst(
int
 hash) {
    HashEntry<K,V>[] tab = table;
    return
 tab[hash & (tab.length - 
1
)];
}

 

同样，这里也是用位操作来确定链表的头部，hash值和HashTable的长度减一做与操作，最后的结果就是hash值的低n位，其中n是HashTable的长度以2为底的结果。

在确定了链表的头部以后，就可以对整个链表进行遍历，看第4行，取出key对应的value的值，如果拿出的value的值是null，则可能这个key，value对正在put的过程中，如果出现这种情况，那么就加锁来保证取出的value是完整的，如果不是null，则直接返回value。

ConcurrentHashMap的put操作

看完了get操作，再看下put操作，put操作的前面也是确定Segment的过程，这里不再赘述，直接看关键的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();
    }
}

 

首先对Segment的put操作是加锁完成的，然后在第五行，如果Segment中元素的数量超过了阈值（由构造函数中的loadFactor算出）这需要进行对Segment扩容，并且要进行rehash，关于rehash的过程大家可以自己去了解，这里不详细讲了。

第8和第9行的操作就是getFirst的过程，确定链表头部的位置。

第11行这里的这个while循环是在链表中寻找和要put的元素相同key的元素，如果找到，就直接更新更新key的value，如果没有找到，则进入21行这里，生成一个新的HashEntry并且把它加到整个Segment的头部，然后再更新count的值。

ConcurrentHashMap的remove操作

Remove操作的前面一部分和前面的get和put操作一样，都是定位Segment的过程，然后再调用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();
    }
}

 

首先remove操作也是确定需要删除的元素的位置，不过这里删除元素的方法不是简单地把待删除元素的前面的一个元素的next指向后面一个就完事了，我们之前已经说过HashEntry中的next是final的，一经赋值以后就不可修改，在定位到待删除元素的位置以后，程序就将待删除元素前面的那一些元素全部复制一遍，然后再一个一个重新接到链表上去，看一下下面这一幅图来了解这个过程：

假设链表中原来的元素如上图所示，现在要删除元素3，那么删除元素3以后的链表就如下图所示：

ConcurrentHashMap的size操作

在前面的章节中，我们涉及到的操作都是在单个Segment中进行的，但是ConcurrentHashMap有一些操作是在多个Segment中进行，比如size操作，ConcurrentHashMap的size操作也采用了一种比较巧的方式，来尽量避免对所有的Segment都加锁。

前面我们提到了一个Segment中的有一个modCount变量，代表的是对Segment中元素的数量造成影响的操作的次数，这个值只增不减，size操作就是遍历了两次Segment，每次记录Segment的modCount值，然后将两次的modCount进行比较，如果相同，则表示期间没有发生过写入操作，就将原先遍历的结果返回，如果不相同，则把这个过程再重复做一次，如果再不相同，则就需要将所有的Segment都锁住，然后一个一个遍历了，具体的实现大家可以看ConcurrentHashMap的源码，这里就不贴了。

 

PS. 原文在：Java并发编程之ConcurrentHashMap

PS：本篇文章的也提供了PDF下载：concurrentHashMap.pdf