• Post Reply Bookmark Topic Watch Topic
  • New Topic

Hashtable Vs ConcurrentHashMap  RSS feed

 
Kumar Jaya
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

What is the difference between a Hashtable and ConcurrentHashMap other than the iterator of ConcurrentHashMap not throwing ConcurrentModificationException?? Are both equally good to be used under multiple threads or one out performs the other??

Thanks in advance
Jaya
 
Henry Wong
author
Sheriff
Posts: 23284
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Hashtable class is a Map implementation that was part of Java since version 1.0. It was "obsoleted" with Hashmap (wrapped with synchronizedMap) in Java 1.2, and but was ported to work just as well as a synchronized Hashmap.

ConcurrentHashMap was added with Java 1.5, as part of the concurrency enhancements. Some features supported by it are ... (1) implemented using optimistic locking, (2) uses reader-writer locks to support simulataneous reads, and (3) uses segmentation to support simultaneous writes.

Henry
 
Kumar Jaya
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Henry,

What is the purpose of optimistic locking in ConcurrentHashMap?? Isnt ConcurrentHashMap locked when accessed by any thread anyways?? Does the implementation take care of it or we have to externally use method to lock it optimistically??

Regards
Jaya
 
Henry Wong
author
Sheriff
Posts: 23284
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kumar Jaya wrote:What is the purpose of optimistic locking in ConcurrentHashMap?? Isnt ConcurrentHashMap locked when accessed by any thread anyways?? Does the implementation take care of it or we have to externally use method to lock it optimistically??


Yeah, using optimistic locking probably doesn't gain much in this regard, as the design is to lock each method, but why not?

Regardless, its an implementation detail -- as a user of the ConcurrentHashMap, you simply know that the class is threadsafe, even though it doesn't use the synchronization mechanism.

Henry
 
Prakash Pasumarthy
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The one feature offered by the synchronized Map or HashTable implementations but not by ConcurrentHashMap is the ability to lock
the map for exclusive access. With Hashtable and synchronizedMap, acquiring the Map lock prevents any other thread
from accessing it. This might be necessary in unusual cases such as adding several mappings atomically, or iterating the
Map several times and needing to see the same elements in the same order.
Where as concurrent collections should be expected to change their contents continuously.
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kumar Jaya wrote:What is the difference between a Hashtable and ConcurrentHashMap other than the iterator of ConcurrentHashMap not throwing ConcurrentModificationException?? Are both equally good to be used under multiple threads or one out performs the other??

In theory, the implementations in the java.util.concurrent package are supposed to be more consistent than the ones in java.util when under load ; just as the performance of a ReentrantLock is supposed to be more consistent than synchronization.

But whether that translates into better performance in practise, only you can judge - and you should test it, not just rely on anecdotal evidence.

Winston
 
Henry Wong
author
Sheriff
Posts: 23284
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prakash Pasumarthy wrote:The one feature offered by the synchronized Map or HashTable implementations but not by ConcurrentHashMap is the ability to lock
the map for exclusive access. With Hashtable and synchronizedMap, acquiring the Map lock prevents any other thread
from accessing it. This might be necessary in unusual cases such as adding several mappings atomically, or iterating the
Map several times and needing to see the same elements in the same order.
Where as concurrent collections should be expected to change their contents continuously.


This is actually a very good point. One common use case is to grab the lock (on the instance of the collection) prior to iterating through the collection; another is to do the same when multiple operations on the collection is needed; this works because the synchronized Map and/or HashTable uses the same lock for its implementation.

With the ConcurrentHashMap, this is not the case -- and in fact, a common lock is not available. The ConcurrentHashMap uses a reader-writer lock to allow parallel reads, and uses segmentation to allow parallel writes, and there isn't a global/common lock to grab.

Henry

 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:With the ConcurrentHashMap, this is not the case -- and in fact, a common lock is not available.

While I totally agree with what you're saying, one thing that a lot of people forget is that almost all the classes in the collections framework are not final, so it wouldn't be too difficult to create your own LockableConcurrentHashMap subclass.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!