Java ConcurrentHashMap 在性能方面优于 HashMap 吗？

Question

我刚刚在阅读《清洁代码》这本书，并遇到了这样的说法：

在 Java 还年轻的时候，Doug Lea 写了一本开创性的书[8] Concurrent 用Java编程。除了这本书，他还开发了几本 线程安全的集合，后来成为 JDK 的一部分 java.util.concurrent 包。该包中的集合是安全的 对于多线程情况，它们表现良好。 事实上， ConcurrentHashMap 实现比 HashMap 在中表现更好 几乎所有情况。它还允许同时并发 读写，它有支持普通复合的方法 否则不是线程安全的操作。如果 Java 5 是 部署环境，开始 ConcurrentHashMap

请注意，在上面的引用中，我使用了“[n]”，其中 n 是某个数字，表示作者提供参考的地方，正如您所看到的，他没有为粗体部分提供任何参考。

并不是我不相信这个说法，而是我很想知道这个说法的支持证据。那么，有没有人知道任何显示ConcurrentHashMap 和HashMap 的性能统计数据的资源？或者谁能​​向我解释为什么 ConcurrentHashMap 比 HashMap 快？

我可能会在休息的时候研究一下 ConcurrentHashMap 在工作中的实现，但现在我想听听其他 SOers 的答案。

Answer 1

Doug Lea 非常擅长这些事情，所以如果有一次他的 ConcurrentHashMap 表现优于 Joshua Bloch 的 HashMap，我不会感到惊讶。然而，从 Java 7 开始，HashMap 的第一个 @author 也成为了 Doug Lea。显然，现在HashMap 没有理由比它的并发表亲慢。

出于好奇，我还是做了一些基准测试。我在 Java 7 下运行它。条目越多，性能越接近。最终ConcurrentHashMap 与HashMap 相差不到3%，这非常了不起。瓶颈实际上是内存访问，俗话说“内存是新磁盘（磁盘是新磁带）”。如果条目在缓存中，两者都会很快；如果条目不适合缓存，两者都会很慢。在实际应用程序中，地图不一定要很大才能与其他地图竞争驻留在缓存中。如果一张地图经常使用，它会被缓存；如果不是，它不会被缓存，这是真正的决定因素，而不是实现（假设两者都是由同一个专家实现的）

public static void main(String[] args)
{
    for(int i = 0; i<100; i++)
    {
        System.out.println();

        int entries = i*100*1000;
        long t0=test( entries, new FakeMap() );
        long t1=test( entries, new HashMap() );
        long t2=test( entries, new ConcurrentHashMap() );

        long diff = (t2-t1)*100/(t1-t0);
        System.out.printf("entries=%,d time diff= %d%% %n", entries, diff);
    }
}


static long test(int ENTRIES, Map map)
{
    long SEED = 0;
    Random random = new Random(SEED);

    int RW_RATIO = 10;

    long t0 = System.nanoTime();

    for(int i=0; i<ENTRIES; i++)
        map.put( random.nextInt(), random.nextInt() );

    for(int i=0; i<RW_RATIO; i++)
    {
        random.setSeed(SEED);
        for(int j=0; j<ENTRIES; j++)
        {
            map.get( random.nextInt() );
            random.nextInt();
        }
    }
    long t = System.nanoTime()-t0;
    System.out.printf("%,d ns %s %n", t, map.getClass());
    return t;
}


static class FakeMap implements Map
{
    public Object get(Object key)
    {
        return null;  
    }
    public Object put(Object key, Object value)
    {
        return null;  
    }
    // etc. etc.
}

Answer 2

如果你只用一个线程访问 HashMap HashMap 最快（它不做任何同步），如果你从多个线程访问它 ConcurrentHashMap 比手动进行粗粒度同步更快。请参阅此处进行一些比较：

http://www.codercorp.com/blog/java/why-concurrenthashmap-is-better-than-hashtable-and-just-as-good-hashmap.html

Answer 3

HashMap 可能较慢的原因是它必须检测 ConcurrentModification 才能知道何时抛出异常。 ConcurrentHashMap 不必检查 modCount 以知道何时抛出（但它确实将它用于 size() 和 isEmpty()）。获取锁非常快，尤其是在单线程情况下，当您已经持有锁时，但检查 modCount 是两次读取和一次跳转，HashMap 必须支付抛出 CoModException 的费用。

我建议阅读你的集合类的源代码，这样你就知道在你进行方法调用时它们做了多少工作。在您有一个仅用于字典 get/put 的完全私有映射的情况下，您通常可以使用精简的 HashMap，而无需任何 modCount 甚至大小跟踪，以提高性能。

Answer 4

这是一种很难以一种或另一种方式证明的橡胶陈述。您如何在“几乎所有情况”中衡量某事？

ConcurrentHashMap 可能比同步的HashMap 更好。争论越多，差异就越大。另一方面，不同步的HashMap 可能比ConcurrentHashMap 更快，因为后者会产生不必要的锁定开销。

---

我还想了解该声明的上下文，以及该书作者提出的支持该声明的证据。还有证据表明散列映射的“几乎所有”用例都涉及同步这一未陈述的假设。