ConcurrentHashMap之实现细节

ConcurrentHashMap是Java 5中支持高并发、高吞吐量的线程安全HashMap实现。在这之前我对ConcurrentHashMap只有一些肤浅的理解，仅知道它采用了多个锁，大概也足够了。但是在经过一次惨痛的面试经历之后，我觉得必须深入研究它的实现。面试中被问到读是否要加锁，因为读写会发生冲突，我说必须要加锁，我和面试官也因此发生了冲突，结果可想而知。还是闲话少说，通过仔细阅读源代码，现在总算理解ConcurrentHashMap实现机制了，其实现之精巧，令人叹服，与大家共享之。

 

 

实现原理

 

锁分离 (Lock Stripping)

 

ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术。它使用了多个锁来控制对hash表的不同部分进行的修改。ConcurrentHashMap内部使用段(Segment)来表示这些不同的部分，每个段其实就是一个小的hash table，它们有自己的锁。只要多个修改操作发生在不同的段上，它们就可以并发进行。

 

有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。这里“按顺序”是很重要的，否则极有可能出现死锁，在ConcurrentHashMap内部，段数组是final的，并且其成员变量实际上也是final的，但是，仅仅是将数组声明为final的并不保证数组成员也是final的，这需要实现上的保证。这可以确保不会出现死锁，因为获得锁的顺序是固定的。不变性是多线程编程占有很重要的地位，下面还要谈到。

 

    /**
     * The segments, each of which is a specialized hash table
     */
    final Segment<K,V>[] segments;

 

 

不变(Immutable)和易变(Volatile)

 

ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。如果使用传统的技术，如HashMap中的实现，如果允许可以在hash链的中间添加或删除元素，读操作不加锁将得到不一致的数据。ConcurrentHashMap实现技术是保证HashEntry几乎是不可变的。HashEntry代表每个hash链中的一个节点，其结构如下所示：

 

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

可以看到除了value不是final的，其它值都是final的，这意味着不能从hash链的中间或尾部添加或删除节点，因为这需要修改next引用值，所有的节点的修改只能从头部开始。对于put操作，可以一律添加到Hash链的头部。但是对于remove操作，可能需要从中间删除一个节点，这就需要将要删除节点的前面所有节点整个复制一遍，最后一个节点指向要删除结点的下一个结点。这在讲解删除操作时还会详述。为了确保读操作能够看到最新的值，将value设置成volatile，这避免了加锁。

 

其它

 

为了加快定位段以及段中hash槽的速度，每个段hash槽的的个数都是2^n，这使得通过位运算就可以定位段和段中hash槽的位置。当并发级别为默认值16时，也就是段的个数，hash值的高4位决定分配在哪个段中。但是我们也不要忘记《算法导论》给我们的教训：hash槽的的个数不应该是2^n，这可能导致hash槽分配不均，这需要对hash值重新再hash一次。（这段似乎有点多余了 ）

 

这是重新hash的算法，还比较复杂，我也懒得去理解了。

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

 

 

 

数据结构

 

关于Hash表的基础数据结构，这里不想做过多的探讨。Hash表的一个很重要方面就是如何解决hash冲突，ConcurrentHashMap和HashMap使用相同的方式，都是将hash值相同的节点放在一个hash链中。与HashMap不同的是，ConcurrentHashMap使用多个子Hash表，也就是段(Segment)。下面是ConcurrentHashMap的数据成员：

 

public class ConcurrentHashMap<K, V> extends AbstractMap<K, V>
        implements ConcurrentMap<K, V>, Serializable {
    /**
     * Mask value for indexing into segments. The upper bits of a
     * key's hash code are used to choose the segment.
     */
    final int segmentMask;

    /**
     * Shift value for indexing within segments.
     */
    final int segmentShift;

    /**
     * The segments, each of which is a specialized hash table
     */
    final Segment<K,V>[] segments;
}

 

所有的成员都是final的，其中segmentMask和segmentShift主要是为了定位段，参见上面的segmentFor方法。

 

每个Segment相当于一个子Hash表，它的数据成员如下：

 

    static final class Segment<K,V> extends ReentrantLock implements Serializable {
private static final long serialVersionUID = 2249069246763182397L;
        /**
         * The number of elements in this segment's region.
         */
        transient volatile int count;

        /**
         * Number of updates that alter the size of the table. This is
         * used during bulk-read methods to make sure they see a
         * consistent snapshot: If modCounts change during a traversal
         * of segments computing size or checking containsValue, then
         * we might have an inconsistent view of state so (usually)
         * must retry.
         */
        transient int modCount;

        /**
         * The table is rehashed when its size exceeds this threshold.
         * (The value of this field is always <tt>(int)(capacity *
         * loadFactor)</tt>.)
         */
        transient int threshold;

        /**
         * The per-segment table.
         */
        transient volatile HashEntry<K,V>[] table;

        /**
         * The load factor for the hash table.  Even though this value
         * is same for all segments, it is replicated to avoid needing
         * links to outer object.
         * @serial
         */
        final float loadFactor;
}

count用来统计该段数据的个数，它是volatile，它用来协调修改和读取操作，以保证读取操作能够读取到几乎最新的修改。协调方式是这样的，每次修改操作做了结构上的改变，如增加/删除节点(修改节点的值不算结构上的改变)，都要写count值，每次读取操作开始都要读取count的值。这利用了Java 5中对volatile语义的增强，对同一个volatile变量的写和读存在happens-before关系。modCount统计段结构改变的次数，主要是为了检测对多个段进行遍历过程中某个段是否发生改变，在讲述跨段操作时会还会详述。threashold用来表示需要进行rehash的界限值。table数组存储段中节点，每个数组元素是个hash链，用HashEntry表示。table也是volatile，这使得能够读取到最新的table值而不需要同步。loadFactor表示负载因子。

 

 

实现细节

 

修改操作

 

先来看下删除操作remove(key)。

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

整个操作是先定位到段，然后委托给段的remove操作。当多个删除操作并发进行时，只要它们所在的段不相同，它们就可以同时进行。下面是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();
            }
        }

 整个操作是在持有段锁的情况下执行的，空白行之前的行主要是定位到要删除的节点e。接下来，如果不存在这个节点就直接返回null，否则就要将e前面的结点复制一遍，尾结点指向e的下一个结点。e后面的结点不需要复制，它们可以重用。下面是个示意图，我直接从这个网站 上复制的（画这样的图实在是太麻烦了，如果哪位有好的画图工具，可以推荐一下）。

 

 

删除元素之前：

 

 

 

删除元素3之后：

 

第二个图其实有点问题，复制的结点中应该是值为2的结点在前面，值为1的结点在后面，也就是刚好和原来结点顺序相反，还好这不影响我们的讨论。

 

整个remove实现并不复杂，但是需要注意如下几点。第一，当要删除的结点存在时，删除的最后一步操作要将count的值减一。这必须是最后一步操作，否则读取操作可能看不到之前对段所做的结构性修改。第二，remove执行的开始就将table赋给一个局部变量tab，这是因为table是volatile变量，读写volatile变量的开销很大。编译器也不能对volatile变量的读写做任何优化，直接多次访问非volatile实例变量没有多大影响，编译器会做相应优化。

 

 

接下来看put操作，同样地put操作也是委托给段的put方法。下面是段的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();
            }
        }

该方法也是在持有段锁的情况下执行的，首先判断是否需要rehash，需要就先rehash。接着是找是否存在同样一个key的结点，如果存在就直接替换这个结点的值。否则创建一个新的结点并添加到hash链的头部，这时一定要修改modCount和count的值，同样修改count的值一定要放在最后一步。put方法调用了rehash方法，reash方法实现得也很精巧，主要利用了table的大小为2^n，这里就不介绍了。

 

修改操作还有putAll和replace。putAll就是多次调用put方法，没什么好说的。replace甚至不用做结构上的更改，实现要比put和delete要简单得多，理解了put和delete，理解replace就不在话下了，这里也不介绍了。

 

 

获取操作

 

首先看下get操作，同样ConcurrentHashMap的get操作是直接委托给Segment的get方法，直接看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;
        }

 

get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是volatile的，也能保证读取到最新的值。接下来就是对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

 

最后，如果找到了所求的结点，判断它的值如果非空就直接返回，否则在有锁的状态下再读一次。这似乎有些费解，理论上结点的值不可能为空，这是因为put的时候就进行了判断，如果为空就要抛NullPointerException。空值的唯一源头就是HashEntry中的默认值，因为HashEntry中的value不是final的，非同步读取有可能读取到空值。仔细看下put操作的语句：tab[index] = new HashEntry<K,V>(key, hash, first, value)，在这条语句中，HashEntry构造函数中对value的赋值以及对tab[index]的赋值可能被重新排序，这就可能导致结点的值为空。这种情况应当很罕见，一旦发生这种情况，ConcurrentHashMap采取的方式是在持有锁的情况下再读一遍，这能够保证读到最新的值，并且一定不会为空值。

 

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

 

 

另一个操作是containsKey，这个实现就要简单得多了，因为它不需要读取值：

        boolean containsKey(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))
                        return true;
                    e = e.next;
                }
            }
            return false;
        }

 

 

跨段操作

 

有些操作需要涉及到多个段，比如说size(), containsValaue()。先来看下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;
    }

 

size方法主要思路是先在没有锁的情况下对所有段大小求和，如果不能成功（这是因为遍历过程中可能有其它线程正在对已经遍历过的段进行结构性更新），最多执行RETRIES_BEFORE_LOCK次，如果还不成功就在持有所有段锁的情况下再对所有段大小求和。在没有锁的情况下主要是利用Segment中的modCount进行检测，在遍历过程中保存每个Segment的modCount，遍历完成之后再检测每个Segment的modCount有没有改变，如果有改变表示有其它线程正在对Segment进行结构性并发更新，需要重新计算。

 

 

其实这种方式是存在问题的，在第一个内层for循环中，在这两条语句sum += segments[i].count; mcsum += mc[i] = segments[i].modCount;之间，其它线程可能正在对Segment进行结构性的修改，导致segments[i].count和segments[i].modCount读取的数据并不一致。这可能使size()方法返回任何时候都不曾存在的大小，很奇怪javadoc居然没有明确标出这一点，可能是因为这个时间窗口太小了吧。size()的实现还有一点需要注意，必须要先segments[i].count，才能segments[i].modCount，这是因为segment[i].count是对volatile变量的访问，接下来segments[i].modCount才能得到几乎最新的值（前面我已经说了为什么只是“几乎”了）。这点在containsValue方法中得到了淋漓尽致的展现：

 

 

    public boolean containsValue(Object value) {
        if (value == null)
            throw new NullPointerException();

        // See explanation of modCount use above

        final Segment<K,V>[] segments = this.segments;
        int[] mc = new int[segments.length];

        // Try a few times without locking
        for (int k = 0; k < RETRIES_BEFORE_LOCK; ++k) {
            int sum = 0;
            int mcsum = 0;
            for (int i = 0; i < segments.length; ++i) {
                int c = segments[i].count;
                mcsum += mc[i] = segments[i].modCount;
                if (segments[i].containsValue(value))
                    return true;
            }
            boolean cleanSweep = true;
            if (mcsum != 0) {
                for (int i = 0; i < segments.length; ++i) {
                    int c = segments[i].count;
                    if (mc[i] != segments[i].modCount) {
                        cleanSweep = false;
                        break;
                    }
                }
            }
            if (cleanSweep)
                return false;
        }
        // Resort to locking all segments
        for (int i = 0; i < segments.length; ++i)
            segments[i].lock();
        boolean found = false;
        try {
            for (int i = 0; i < segments.length; ++i) {
                if (segments[i].containsValue(value)) {
                    found = true;
                    break;
                }
            }
        } finally {
            for (int i = 0; i < segments.length; ++i)
                segments[i].unlock();
        }
        return found;
    }

 

同样注意内层的第一个for循环，里面有语句int c = segments[i].count; 但是c却从来没有被使用过，即使如此，编译器也不能做优化将这条语句去掉，因为存在对volatile变量count的读取，这条语句存在的唯一目的就是保证segments[i].modCount读取到几乎最新的值。关于containsValue方法的其它部分就不分析了，它和size方法差不多。

 

 

跨段方法中还有一个isEmpty()方法，其实现比size()方法还要简单，也不介绍了。最后简单地介绍下迭代方法，如keySet(), values(), entrySet()方法，这些方法都返回相应的迭代器，所有迭代器都继承于Hash_Iterator类(提交时居然提醒我不能包含sh It，只得加了下划线)，里实现了主要的方法。其结构是：

 

    abstract class Hash_Iterator{
        int nextSegmentIndex;
        int nextTableIndex;
        HashEntry<K,V>[] currentTable;
        HashEntry<K, V> nextEntry;
        HashEntry<K, V> lastReturned;
    }

 

 nextSegmentIndex是段的索引，nextTableIndex是nextSegmentIndex对应段中中hash链的索引，currentTable是nextSegmentIndex对应段的table。调用next方法时主要是调用了advance方法：

 

 

        final void advance() {
            if (nextEntry != null && (nextEntry = nextEntry.next) != null)
                return;

            while (nextTableIndex >= 0) {
                if ( (nextEntry = currentTable[nextTableIndex--]) != null)
                    return;
            }

            while (nextSegmentIndex >= 0) {
                Segment<K,V> seg = segments[nextSegmentIndex--];
                if (seg.count != 0) {
                    currentTable = seg.table;
                    for (int j = currentTable.length - 1; j >= 0; --j) {
                        if ( (nextEntry = currentTable[j]) != null) {
                            nextTableIndex = j - 1;
                            return;
                        }
                    }
                }
            }
        }

不想再多介绍了，唯一需要注意的是跳到下一个段时，一定要先读取下一个段的count变量。 

 

这种迭代方式的主要效果是不会抛出ConcurrentModificationException。一旦获取到下一个段的table，也就意味着这个段的头结点在迭代过程中就确定了，在迭代过程中就不能反映对这个段节点并发的删除和添加，对于节点的更新是能够反映的，因为节点的值是一个volatile变量。

 

结束语

 

ConcurrentHashMap是一个支持高并发的高性能的HashMap实现，它支持完全并发的读以及一定程度并发的写。ConcurrentHashMap的实现也是很精巧，充分利用了最新的JMM规范，值得学习，却不值得模仿。最后由于本人水平有限，对大师的作品难免有误解，如果存在，还望大牛们不吝指出。

 

 

 

 

参考文章：

http://www.ibm.com/developerworks/java/library/j-jtp08223/，这个是讨论的是Doug Lea's util.concurrent包中的ConcurrentHashMap的实现，不过大致思想是一致的。

 

http://floatingpoint.tinou.com/2008/09/performance-optimization-in-concurrenthashmap.html

 

 

评论

38 楼 miscocox 2015-03-16  

我也遇到同样的问题，我也是同样的回答。LZ分析很透彻啊~谢谢了~

37 楼 mercyblitz 2009-05-03  

iamjxc 写道

ConcurrentHashMap 不是绝对线程安全的.
谁举个ConcurrentHashMap的最佳应用场景呢?

应该没有最佳之说，只能说在性能和数据一致性方面，它可能是比较好的一个途径。

如果要可靠的话，还是要使用Collections.synchronizedMap(Map map)方法，利用的synchronized机制，保证数据的一致性，然而ConcurrentHashMap只是保证Happens-before关系。

36 楼 mercyblitz 2009-05-03  

marlonyao 写道

mercyblitz 写道

marlonyao 写道

dlovek 写道

恩，我有看到在Segment的删除/添加方法都是先修改了modCount然后修改了volatile的count值。
在containsValue方法中，“内层的第一个for循环，里面有语句int c = segments[i].count; 但是c却从来没有被使用过，即使如此，编译器也不能做优化将这条语句去掉，因为存在对volatile变量count的读取，这条语句存在的唯一目的就是保证segments[i].modCount读取到几乎最新的值”，这个就不理解了。

见我前面的回复，如果不先读count，就有可能读到modCount很久以前的陈旧值。

volatile 不能100％保证读到的是最新的数值，也可说volatile是轻量级别的sychronized。

volatile保证100%读取到最新的数据，对这里来说，它保证100%读取到count的最新值，但是对非volatile变量就不一样了。

volatile在高并发的情况下是不能保证的，它能保证HB的关系，但是HB不能保证是最新的值，必须通过synchronized关键字或者Lock机制来保证从主存中获取最近的数值，volatile只是不让数值保存在寄存器来中，并不是完全真实主存的值，可能是Thread stack中一个比较新的数值。

35 楼 C_J 2009-04-17  

zhaomingzm_23 写道

大师的作品，还在学习中。

34 楼 wang5566156 2009-04-17  

e 是什么事件呀

33 楼 zhaomingzm_23 2009-03-17  

大师的作品，还在学习中。

32 楼 dlovek 2009-03-13  

<div class="quote_title">holan 写道</div>
<div class="quote_div">为什么删除的时候要吧原来的节点复制一次，不能直接删除吗？</div>
<p> </p>
<p>因为next属性为final的，不可以被重置。直接删除，就无法保持链结果的连续性了。</p>

31 楼 dlovek 2009-03-13  

<div class="quote_title">marlonyao 写道</div>
<div class="quote_div">
<div class="quote_title">dlovek 写道</div>
<div class="quote_div"><br />marlonyao 写道<br /><br />&amp;nbsp;<br />其实这种方式是存在问题的，在第一个内层for循环中，在这两条语句sum += segments[i].count; mcsum += mc[i] = segments[i].modCount;之间，其它线程可能正在对Segment进行结构性的修改，导致segments[i].count和segments[i].modCount读取的数据并不一致。这可能使size()方法返回任何时候都不曾存在的大小，很奇怪javadoc居然没有明确标出这一点，可能是因为这个时间窗口太小了吧。size()的实现还有一点需要注意，必须要先segments[i].count，才能segments[i].modCount，这是因为segment[i].count是对volatile变量的访问，接下来segments[i].modCount才能得到几乎最新的值（前面我已经说了为什么只是“几乎”了）。<br /><br />楼主写的非常好，又使我明白的不少东西。这个地方还是不理解，为什么需要首先调用一次volatile变量才使的modCount几乎可以得到最新的值?<br /></div>
</div>
<div class="quote_div"><br /><br />写volatile变量和它之前的读写操作是不能reorder的，读volatile变量和它之后的读写操作也是不能reorder的。<br />修改modCount发生在修改count之前，由于count是volatile变量，修改modCount不能和写count的操作reorder，读取count和它之后的操作，比如读取modCount，不能reorder。有了这两个不能reorder才能保证读取了count之后，能读到线程在写count之前的写入的modCount值，这个modCount值是几乎最新的。<br />如果在读modCount之前不读count，读modCount甚至可能会reorder到写modCount之前。<br /><br />用reorder解释总是太复杂了，不如用happens-before来得简洁。当一个线程I对count的读时，它读到的值必定是另一个线程，假设是线程II，最近对count的写。这个两个操作存在happens-before关系，即线程II对count的写happens-before线程I对count的读，记作：II：W(count) &lt; I：R(count)。单线程的happens-before规则，又有II：W(modCount) &lt; II：<span style="color: #ff0000;">W</span>(count)（查看源代码会发现在写count之前必定有写modCount），以及 I：R(count) &lt; I：R(modCount)，<span style="color: #000000;">根据传递规则有，II：<span style="color: #ff0000;">W</span>(modCount) &lt; I：<span style="color: #ff0000;">R</span>(modCount)</span>，这就是说线程I至少能够读取到线程II写count之前的modCount值。我曾经写了一篇关于happens-before的文章，有些表达可能有误，但大致还是对的，http://www.iteye.com/topic/260515。<br /><br /><br />不理解的话，也只能告诉你结论了，<span style="color: #000000;">如果没有对count的写的话（对volatile的写是一种同步操作），读modCount可能读到很久很久很久以前的值</span>（初始值0都有可能）。<br /><br />期待高人做更简洁的解释吧。</div>
<p>看了半天才看明白，不知道修改的对不对？</p>

30 楼 iamjxc 2009-03-13  

ConcurrentHashMap 不是绝对线程安全的.
谁举个ConcurrentHashMap的最佳应用场景呢?

29 楼 holan 2009-03-11  

为什么删除的时候要吧原来的节点复制一次，不能直接删除吗？

28 楼 Laynepeng 2009-03-11  

原来的HashTable一锁就锁掉了整个map，现在这个锁只锁了一个segments,锁的范围小了，很多情况下可以不所解决问题。。。于是效率提高了。。。

27 楼 kevinwong 2009-03-11  

marlonyao 写道

kevinwong 写道

marlonyao 写道kevinwong 写道看完文章后有个感觉 ConcurrentHashMap适合在高读并发低写并发的情况下使用 如果在高写并发的情况下使用 连get的安全性都不能保障 是这个意思吗？ 写并发的负载到什么程度ConcurrentHashMap才会不安全？


get总是安全的。

引用 get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是volatile的，也能保证读取到最新的值。接下来就是对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

这是原话 而且新put的entity都是放到节点头的 那说明在一个线程内put的entity在另一个线程内不保证能get出来 这是我的理解

是的。但是get能够看到调用get方法之前所有已经完成的put（因为如果发生结构性改变它会写count），虽然可能看不到正在进行的put操作（还没有写count）。这是一个很小的时间窗口，这不可避免，因为get没有同步。这并不是说get不安全，即使get操作时，其它线程在put，get也能看到一致的hash链（与HashMap相比较）。在HashMap中，假设put方法是同步的，get没有同步，get有可能看到实际上从不存在hash链。

get方法总是返回最近put过的数据，这句话说得很别扭，却是很重要的。假设其它线程先后调用了put("a", 1)，put("a", 2)，put("a", 3)，这里能够使用“先后”，是因为put方法是同步的，put方法是排序的，每一个时刻只能够发生一个put方法。接着一个线程调用get("a")方法，并且另一个线程正在调用put("a", 4)方法，那么get("a")会返回3或者4，完全取决于("a")访问结点的值（读value)和put("a", 4)写结点的值(写value)哪个先发生（读volatile变量和写volatile总有个先后顺序，读写普通变量就不一定了，它们可能同时发生），这时put不会发生结构性更新。如果在调用get("a")时，另一个线程正在调用remove("a")，get方法要么返回3，要么返回null，这取决于get方法中getFirst(hash)返回的到底是remove("a")之前还是之后的头结点，而绝不会返回1, 2或任何其它的值。

受教了 谢谢:)

26 楼 whaosoft 2009-03-11  

算法好难!~

25 楼 zhenjia 2009-03-10  

thanks.

24 楼 marlonyao 2009-03-10  

kevinwong 写道

marlonyao 写道kevinwong 写道看完文章后有个感觉 ConcurrentHashMap适合在高读并发低写并发的情况下使用 如果在高写并发的情况下使用 连get的安全性都不能保障 是这个意思吗？ 写并发的负载到什么程度ConcurrentHashMap才会不安全？


get总是安全的。

引用 get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是volatile的，也能保证读取到最新的值。接下来就是对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

这是原话 而且新put的entity都是放到节点头的 那说明在一个线程内put的entity在另一个线程内不保证能get出来 这是我的理解

是的。但是get能够看到调用get方法之前所有已经完成的put（因为如果发生结构性改变它会写count），虽然可能看不到正在进行的put操作（还没有写count）。这是一个很小的时间窗口，这不可避免，因为get没有同步。这并不是说get不安全，即使get操作时，其它线程在put，get也能看到一致的hash链（与HashMap相比较）。在HashMap中，假设put方法是同步的，get没有同步，get有可能看到实际上从不存在hash链。

get方法总是返回最近put过的数据，这句话说得很别扭，却是很重要的。假设其它线程先后调用了put("a", 1)，put("a", 2)，put("a", 3)，这里能够使用“先后”，是因为put方法是同步的，put方法是排序的，每一个时刻只能够发生一个put方法。接着一个线程调用get("a")方法，并且另一个线程正在调用put("a", 4)方法，那么get("a")会返回3或者4，完全取决于("a")访问结点的值（读value)和put("a", 4)写结点的值(写value)哪个先发生（读volatile变量和写volatile总有个先后顺序，读写普通变量就不一定了，它们可能同时发生），这时put不会发生结构性更新。如果在调用get("a")时，另一个线程正在调用remove("a")，get方法要么返回3，要么返回null，这取决于get方法中getFirst(hash)返回的到底是remove("a")之前还是之后的头结点，而绝不会返回1, 2或任何其它的值。

23 楼 h521999 2009-03-10  

看了以后，更加清楚了，感谢楼主！

22 楼 kevinwong 2009-03-10  

marlonyao 写道

kevinwong 写道

看完文章后有个感觉 ConcurrentHashMap适合在高读并发低写并发的情况下使用 如果在高写并发的情况下使用 连get的安全性都不能保障 是这个意思吗？ 写并发的负载到什么程度ConcurrentHashMap才会不安全？

get总是安全的。

引用

get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count变量，通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是volatile的，也能保证读取到最新的值。接下来就是对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是final的，这是通过getFirst(hash)方法返回，也就是存在table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash)之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽然可能不是最新的。要得到最新的数据，只有采用完全的同步。

这是原话 而且新put的entity都是放到节点头的 那说明在一个线程内put的entity在另一个线程内不保证能get出来 这是我的理解

21 楼 marlonyao 2009-03-10  

kevinwong 写道

看完文章后有个感觉 ConcurrentHashMap适合在高读并发低写并发的情况下使用 如果在高写并发的情况下使用 连get的安全性都不能保障 是这个意思吗？ 写并发的负载到什么程度ConcurrentHashMap才会不安全？

get总是安全的。

20 楼 marlonyao 2009-03-10  

mercyblitz 写道

marlonyao 写道

dlovek 写道

恩，我有看到在Segment的删除/添加方法都是先修改了modCount然后修改了volatile的count值。
在containsValue方法中，“内层的第一个for循环，里面有语句int c = segments[i].count; 但是c却从来没有被使用过，即使如此，编译器也不能做优化将这条语句去掉，因为存在对volatile变量count的读取，这条语句存在的唯一目的就是保证segments[i].modCount读取到几乎最新的值”，这个就不理解了。

见我前面的回复，如果不先读count，就有可能读到modCount很久以前的陈旧值。

volatile 不能100％保证读到的是最新的数值，也可说volatile是轻量级别的sychronized。

volatile保证100%读取到最新的数据，对这里来说，它保证100%读取到count的最新值，但是对非volatile变量就不一样了。

19 楼 marlonyao 2009-03-10  

unsid 写道

final Segment<K,V>[] segments;

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

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

我对此处的segments不理解,这里的segments数组是干吗的?我起初还以为相当于HashMap中的Entity[],仔细一看,每个segment里面都有一个HashEntry[],这个应当是真正哈西表按照楼主说的,每个用户操作在不同的segment上不同segment有不同的锁,那让segment[]充当Entity[],而每个segment里仅有一个HashEntry链表,这样只有两个用户删除哈西值相同的元素时才需要同步.

为虾米先要segmentFor(hash)而后在remove方法里又哈西算一次坐标?       
  int index = hash & (tab.length - 1);  
  HashEntry<K,V> first = tab[index]; 

每个Segment包含多个hash链。