blocks|key|261455|text|这是一种很难以任何方式证明的橡皮声明。你如何在“几乎所有的情况”中衡量一件事？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|261456|ConcurrentHashMap可能比同步的HashMap更好。争论越多，差异就越大。另一方面，非同步的HashMap可能比ConcurrentHashMap更快，因为后者会产生不必要的锁定开销。|offset|length|style|CODE|261457|261458|我也想看看这句话的背景，以及这本书的作者提出了什么证据来支持它。以及散列映射的“几乎所有”用例都涉及同步这一未声明假设的证据。|261459|entityMap^0|0|0|H|N|7|1H|7|1R|H|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@$D|O|E|P|F|G]|$D|Q|E|R|F|G]|$D|S|E|T|F|G]|$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|L|$]]

This is the kind of rubbery statement that is hard to prove one way or the other. How do you measure something in "nearly all situations"?

A <code>ConcurrentHashMap</code> is likely to be better than a synchronized <code>HashMap</code>. The more contention there is, the more significant the difference will be. On the other hand an unsynchronized <code>HashMap</code> is likely to be faster than a <code>ConcurrentHashMap</code>, because of the overhead of unnecessary locking in the latter case.

<hr>

I'd also like to see the context for that statement, and what evidence the book's author puts forward to support it. And the evidence for the unstated assumption that "nearly all" use-cases for hash maps involve synchronization.

blocks|key|2952168|text|如果你只用一个线程访问HashMap，HashMap是最快的(它不做任何同步)，如果你从多个线程访问它，ConcurrentHashMap比手工进行粗粒度的同步要快。这里有一个小小的比较：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2952169|http://www.codercorp.com/blog/java/why-concurrenthashmap-is-better-than-hashtable-and-just-as-good-hashmap.html|offset|length|2952170|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|33|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

If you are accessing the HashMap with only a single thread HashMap is fastest (it does not do any synchronization), if you are accessing it from multiple threads ConcurrentHashMap is faster than doing the synchronization coarse-grained by hand. See here for a little comparison: 

<a href="http://www.codercorp.com/blog/java/why-concurrenthashmap-is-better-than-hashtable-and-just-as-good-hashmap.html" rel="noreferrer">http://www.codercorp.com/blog/java/why-concurrenthashmap-is-better-than-hashtable-and-just-as-good-hashmap.html</a>

blocks|key|263160|text|Doug+Lea非常擅长这些事情，所以如果有一次他的ConcurrentHashMap比Joshua+Bloch的HashMap表现更好，我也不会感到惊讶。然而，从Java7开始，HashMap的第一个@作者也变成了Doug+Lea。显然，现在HashMap没有理由比它的并发表亲慢。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|263161|出于好奇，我还是做了一些基准测试。我在Java7下运行，条目越多，性能越接近。最终，ConcurrentHashMap在HashMap的3%25以内，这是相当值得注意的。瓶颈实际上是内存访问，俗话说得好，“内存就是新的磁盘(而磁盘就是新的磁带)”。如果条目在缓存中，则两者都是快速的；如果条目不能放入缓存中，则两者都将变慢。在实际应用中，地图并不一定要很大才能与其他地图竞争缓存中的内容。如果地图经常被使用，它就会被缓存；如果不经常使用，它就不会被缓存，而这才是真正的决定因素，而不是实现(假设两者都是由同一个专家实现的)|263162|public+static+void+main(String[]+args)
{
++++for(int+i+=+0;+i<100;+i%2B%2B)
++++{
++++++++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=%25,d+time+diff=+%25d%25%25+%25n",+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%2B%2B)
++++++++map.put(+random.nextInt(),+random.nextInt()+);

++++for(int+i=0;+i<RW_RATIO;+i%2B%2B)
++++{
++++++++random.setSeed(SEED);
++++++++for(int+j=0;+j<ENTRIES;+j%2B%2B)
++++++++{
++++++++++++map.get(+random.nextInt()+);
++++++++++++random.nextInt();
++++++++}
++++}
++++long+t+=+System.nanoTime()-t0;
++++System.out.printf("%25,d+ns+%25s+%25n",+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.
}|code-block|syntax|javascript|263163|entityMap^0|Q|H|1L|7|2I|7|3E|7|0|16|H|1O|7|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|N|$]]

Doug Lea is extremely good at these things, so I won't be surprised if at one time his <code>ConcurrentHashMap</code> performs better than Joshua Bloch's <code>HashMap</code>. However as of Java 7, the first @author of <code>HashMap</code> has become Doug Lea too. Obviously now there's no reason <code>HashMap</code> would be any slower than its concurrent cousin.
Out of curiosity, I did some benchmark anyway. I run it under Java 7. The more entries there are, the closer the performance is. Eventually <code>ConcurrentHashMap</code> is within 3% of <code>HashMap</code>, which is quite remarkable. The bottleneck is really memory access, as the saying goes, &quot;memory is the new disk (and disk is the new tape)&quot;. If the entries are in the cache, both will be fast; if the entries don't fit in cache, both will be slow. In real applications, a map doesn't have to be big to compete with others for residing in cache. If a map is used often, it's cached; if not, it's not cached, and that is the real determining factor, not the implementations (given both are implemented by the same expert)
<pre><code>public static void main(String[] args)
{
 for(int i = 0; i&lt;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(&quot;entries=%,d time diff= %d%% %n&quot;, 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&lt;ENTRIES; i++)
 map.put( random.nextInt(), random.nextInt() );

 for(int i=0; i&lt;RW_RATIO; i++)
 {
 random.setSeed(SEED);
 for(int j=0; j&lt;ENTRIES; j++)
 {
 map.get( random.nextInt() );
 random.nextInt();
 }
 }
 long t = System.nanoTime()-t0;
 System.out.printf(&quot;%,d ns %s %n&quot;, 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.
}
</code></pre>

blocks|key|263165|text|HashMap可能较慢的原因是因为它必须检测ConcurrentModification才能知道何时抛出异常。ConcurrentHashMap不需要检查modCount就能知道什么时候抛出(但它确实将它用于size()和isEmpty())。获取锁是非常快的，特别是在单线程的情况下，当您已经持有锁，但检查modCount是两次读取和一个跳转，如果不等于，HashMap必须支付抛出CoModException。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|263166|我建议您阅读您的集合类的源代码，这样您就可以在进行方法调用时知道它们正在做多少工作。当你只有一个完全私有的map用于字典get/put的时候，你通常可以使用一个没有任何modCount甚至大小跟踪的精简的HashMap来提升性能。|263167|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The reason a HashMap could be slower is because it has to detect ConcurrentModification to know when to throw an exception. ConcurrentHashMap does not have to check modCount to know when to throw (but it does use it for size() and isEmpty()). Acquiring a lock is very fast, especially so in single-threaded situations when you already hold the lock, but checking modCount is two reads and a jump-if-not-equal that HashMap must pay to throw CoModException.

I recommend reading the source of your collections classes, so you know how much work they are doing when you make a method call. In situations when you have a completely private map for dictionary get/put only, you can often used a stripped down HashMap without any modCount or even size tracking for added performance boost.

I was just reading the book Clean Code and came across this statement:

<blockquote>
 When Java was young Doug Lea wrote the seminal book[8] Concurrent
 Programming in Java. Along with the book he developed several
 thread-safe collection, which later became part of the JDK in the
 <code>java.util.concurrent</code> package. The collections in that package are safe
 for multithreaded situations and they perform well. In fact, the
 <code>ConcurrentHashMap</code> implementation performs better than HashMap in
 nearly all situations. It also allows for simultaneous concurrent
 reads and writes, and it has methods supporting common composite
 operations that are otherwise not thread safe. If Java 5 is the
 deployment environment, start with 
 <code>ConcurrentHashMap</code>
</blockquote>

Note that in the above quote I used "[n]", where n is some number, to indicate the places where the author provided references, and as you can see he did not provide any reference for the bold part.

Not that I don't believe this statement, but I would love to know the supporting evidences of this statement. So, does anyone know any resources that shows the performance statistics for both <code>ConcurrentHashMap</code> and <code>HashMap</code>? Or can anyone explain to me why ConcurrentHashMap is faster than HashMap? 

I probably will look into ConcurrentHashMap's implementation at work when I'm taking a break, but for now I would like to hear the answers from fellow SOers.

Java ConcurrentHashMap is better than HashMap performance wise?

Java

我刚刚读了“干净的代码”这本书，偶然发现了这样一句话：在Java很小的时候，Doug Lea就用Java语言编写了开创性的book8并发编程。除了这本书，他还开发了几个线程安全的集合，这些集合后来成为java.util.concurrent包中JDK的一部分。该包中的集合对于多线程情况是安全的，并且它们执行得很好。事实...

问Java ConcurrentHashMap比HashMap性能好吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java ConcurrentHashMap比HashMap性能好吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java ConcurrentHashMap比HashMap性能好吗？
EN