• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When to use Concurrent HashMap and when to choose HashTable.

 
Ranch Hand
Posts: 2925
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Both concurrent HashMap and HashTable are used in a synchronized context. How to choose which one to use.
thanks
 
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:
Both concurrent HashMap and HashTable are used in a synchronized context. How to choose which one to use.
thanks



What do you mean by both ConcurrentHashMap and HashTable are used in a synchronized context? Are you talking about your use of the objects, or implying something about the internal implementations of the objects? ConcurrentHashMap does not use synchronization to lock the object for all accesses. Read operations will never block, and as far as I can tell from the Javadoc it's possible that write operations won't block either depending on how many are occurring at the same time. All operations are thread safe, but the behaviour will not be the same as HashTable. From the ConcurrentHashMap Javadoc:

This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details



If threads are reading from a ConcurrentHashMap at the same time as another thread is performing an aggregate operation (such as putAll) then it is possible that the reading thread will see only part of the putAll operation (it won't be atomic), whereas in HashTable the operation will be atomic because of the synchronization. ConcurrentHashMap does not provide an in-build method to lock the entire object.

So if your map will only ever be read from then I'd say go for ConcurrentHashMap. If it will be read and updated from separate threads and you need aggregate operations to be atomic then go for HashTable, otherwise again I'd say go for ConcurrentHashMap.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You also have the difference that Hashtable doesn't support nulls.
 
Monica Shiralkar
Ranch Hand
Posts: 2925
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ConcurrentHashMap does not support nulls either.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike. J. Thompson wrote:ConcurrentHashMap does not support nulls either.



Wow. All these years of using ConcurrentHashMap, and I didn't know that. I guess I never needed to have nulls either...

Have a cow,
Henry
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To be honest I wasn't aware either until I read the Javadoc today. It throws a NullPointerException if either the key or value are null.

Thanks for the cow!
 
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike. J. Thompson wrote:To be honest I wasn't aware either until I read the Javadoc today. It throws a NullPointerException if either the key or value are null.

Thanks for the cow!



javadoc is your friend. It came with java 1.0 too ;-)

Too many times have I had to resort to the sources although when available in third party libraries because no javadoc avail.

But definetely, javadoc was cool when it came out.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Class java.util.Hashtable is a legacy collection class, from before Java version 1.2. You shouldn't use it at all.

Just use a regular HashMap, and if you need synchronization, use ConcurrentHashMap. But do read about the thread safety of ConcurrentHashMap before you use it, so you understand what it means.
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesper de Jong wrote:Class java.util.Hashtable is a legacy collection class, from before Java version 1.2. You shouldn't use it at all.

Just use a regular HashMap, and if you need synchronization, use ConcurrentHashMap. But do read about the thread safety of ConcurrentHashMap before you use it, so you understand what it means.



Jee, learn about synchronized statement first. We normally use specific Object to synchronize and monitor, not the instance nor the the class (static) monitor to handle things.

Usually, for best performance, we rather synchronize on our own defined monitors.

Nothing is magic.
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

A.J. Côté wrote:

Jesper de Jong wrote:Class java.util.Hashtable is a legacy collection class, from before Java version 1.2. You shouldn't use it at all.

Just use a regular HashMap, and if you need synchronization, use ConcurrentHashMap. But do read about the thread safety of ConcurrentHashMap before you use it, so you understand what it means.



Jee, learn about synchronized statement first. We normally use specific Object to synchronize and monitor, not the instance nor the the class (static) monitor to handle things.

Usually, for best performance, we rather synchronize on our own defined monitors.

Nothing is magic.



Gee. Learn about the concurrency API first. Synchronized is old hat. Use locks and conditions.
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

A.J. Côté wrote:
Jee, learn about synchronized statement first. We normally use specific Object to synchronize and monitor, not the instance nor the the class (static) monitor to handle things.

Usually, for best performance, we rather synchronize on our own defined monitors.



Gee. Learn about the concurrency API first. Synchronized is old hat. Use locks and conditions.



Also, the ConcurrentHashMap has lots of features that enables "performance" -- segmentation, reader/writer locks, and of course, the locking is done optimistically. If you are wrapping it around a synchronized object, this definitely doesn't achieve "best performance".

Henry
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

A.J. Côté wrote:

Jee, learn about synchronized statement first. We normally use specific Object to synchronize and monitor, not the instance nor the the class (static) monitor to handle things.

Usually, for best performance, we rather synchronize on our own defined monitors.

Nothing is magic.



Synchronization reduces performance by a very large amount. It is much much better to use non-blocking thread safety techniques wherever possible. The synchronized keyword is not quite as out-of-date as the wait/notify methods on Object, but I'd say not too far behind.

I occasionally use locking if I am being very lazy and do not care about performance. I also use locks for Conditionals when I need inter-thread communication. But that's about it.
 
reply
    Bookmark Topic Watch Topic
  • New Topic