Comments on: Performance problems in ConcurrentHashMap vs synchronized HashMap

By: Ismael Juma

Ismael Juma — Mon, 29 Jun 2009 19:44:33 +0000

Greg,
Yes, but ConcurrentHashMap is mostly lock-free on gets (it just locks if it finds an Entry with value null). Locks are used for puts though. And if you can at most have 8/16 concurrent threads, then 100 segments seems high. To quote from the documentation:
“Ideally, you should choose a value to accommodate as many
* threads as will ever concurrently modify the table. Using a
* significantly higher value than you need can waste space and time”
Note that it says “concurrently modify”. If you only have 8/16 cores, it’s unlikely you will have 100 threads concurrently modifying the map. Anyway, the documentation also says that underestimates or overestimates within an order of magnitude are do not usually have a noticeably impact.
I will stop here as I think I have made my point by now.
Ismael

By: Greg Luck

Greg Luck — Mon, 29 Jun 2009 11:42:32 +0000

Kevin
Ehcache has the Apache 2 license. Version 1.6 has NO dependencies, just JDK 1.5 and higher.
Ehcache will be the fastest implementation you can find for an in-process cache. Caches add things like eviction, expiry, listeners etc. If you really just need concurrent maps/lists/sets I would recommend java.util.concurrent. The Backport Concurrent library has quite a lot more stuff so it is also worth a look.

By: Greg Luck

Greg Luck — Mon, 29 Jun 2009 10:48:34 +0000

Sure.
By number of threads I am referring to the number the program is using. With synchronized, threads queue up to get in. The time taken to get in increases as the number of threads go up.
The number of threads that can be executed _concurrently_ depends on the number of cores in the system. Our production experience is with 8 cores.

By: Kevin

Kevin — Sun, 28 Jun 2009 10:28:52 +0000

Hi there,
I am working on an open-source project that would benefit from having the fastest map/list/set lookup times. I am basing it on at least JDK 1.5, although with 1.7 due out soon, 1.6 has been out long enough that we may require 1.6. I am curious if your library is a) allowed to be distributed with another project so that it can be built and run without requiring another download, and b) does it allow for faster lookups, sorts, even puts than the current JDK map implementation (and list/set for that matter)?
Thanks.

By: Ismael Juma

Ismael Juma — Sat, 27 Jun 2009 19:00:48 +0000

I forgot to mention, the reason why I bring this up is that the number of segments is affected by the concurrency level and this affects the performance of things like size and iteration.
Ismael

By: Ismael Juma

Ismael Juma — Sat, 27 Jun 2009 18:59:08 +0000

Hi Greg,
Maybe there’s a terminology issue here. It’s quite possible for people to use hundreds or thousands of threads. However, the concurrency level is about the number of concurrent threads and that is limited by the number of logical cores in your system.
Systems that provide hundreds or thousands of logical cores are quite rare these days (Azul aside).
Best,
Ismael

By: Greg Luck

Greg Luck — Fri, 26 Jun 2009 20:54:29 +0000

It is not uncommon for Ehcache caches to be hit by hundreds or in some cases thousands of concurrent threads. Having said that, access times for put and get for a range of thread levels are below 10 microseconds. I have tested up to 2000 concurrent threads with good results.

By: Ismael Juma

Ismael Juma — Fri, 26 Jun 2009 20:13:35 +0000

Hi Greg,
How did you arrive to the number 100 for concurrency level? It seems to me that it’s a bit high for the common case.
It would also be interesting to see how NonBlockingHashMap compares.
Best,
Ismael