Comments on: Why ConcurrentHashMap is better than Hashtable and just as good as a HashMap

By: Rags

Rags — Fri, 25 Nov 2011 11:29:20 +0000

Better explanation is here: http://stackoverflow.com/questions/2836267/concurrenthashmap-in-java specifically “All operations are threadsafe, but there is no happens before promise like there would be with a synchronized map. What you see when you look in a ConcurrentHashMap is the results of the most recently completed operations. Some of which may have begun significantly later in time than when you started trying to look. It works rather like a read-committed database isolation, whereas a synchronized map works more like a serializable database isolation. – Affe May 14 ’10 at 17:46″

By: Aaron Li

Aaron Li — Sat, 17 Sep 2011 03:13:54 +0000

If I am not wrong the maximum number of lock is 2 power 16, not 16 only

By: Vivek

Vivek — Mon, 07 Feb 2011 16:51:39 +0000

Well,
Your code snippet is not thread-safe if seen from the actual implementation point of view. Bcoz the entire operation of search & insertion of Key should have been an atomic operation but is not.

But however, you still are safe from any threading issues with regard to the above implementation bcoz, the threadId in your case is specific to the calling Thread. So, at any given point in time the Thread will check its own identity in the map and hence you are left safe.

By: Javin Paul

Javin Paul — Sat, 08 Jan 2011 07:03:59 +0000

ConcurrentHashMap is indeed best choice in case of multithreaded environment if numbers of reader is much greater than number of writer to avoid contention and to increase throughput and performance but deciding between SynchrnozedHashMap and ConcurrentHashMap is still requires understanding of usecases and actual environment. Thanks Javin FIX Protocol tutorial

By: anshuiitk

anshuiitk — Sun, 12 Dec 2010 19:27:15 +0000

In the 5th para you do explain about how CHMs could have null. I wrote an article about why CHMs dont offer null values (http://anshuiitk.blogspot.com/2010/12/why-concurrenthashmap-does-not-support.html). However the best tradeof is to use putIfAbsent in case of CHMs. Its very important. Nice and informative article.

By: Shrini

Shrini — Thu, 04 Mar 2010 05:18:30 +0000

@rajeshksv

How about storing context in thread local ? But this does not answer your question though

By: WasserbettenGuerilla

WasserbettenGuerilla — Thu, 28 Jan 2010 17:58:42 +0000

Im wondering if the ConcurrentHashMap is only fast if it comes to multiple thread operations. I tried it in a single threaded application and i performed worse than a hashtable.. So what if there are only two threads accessing the datastructure, is Hastable or CHM faster?

Regards

By: rajeshksv

rajeshksv — Mon, 14 Sep 2009 06:49:20 +0000

Nice tutorial.It clearly explains why Concurrent hashmap is to be used
I am using Concurrent Hashmap for this code— Is this threadsafe??
Why cant I use hashmap atleast in this case where no two threads access the same key(since I am using threadId itself as hashmap key) and no thread iterates over the map and all the threads will only put/get values

private static Map threadData = new ConcurrentHashMap();
public static Context getContext() {
String threadId = String.valueOf(Thread.currentThread().getId());
if (threadData.get(threadId) == null) {
Context context = new Context();
threadData.put(threadId, context);
}
return (threadData.get(threadId));
}

Thanks in Advance