wood burning stoves*
The moose likes Java in General and the fly likes concurrent access to HashMap Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "concurrent access to HashMap" Watch "concurrent access to HashMap" New topic
Author

concurrent access to HashMap

nandkishor rao
Ranch Hand

Joined: May 24, 2006
Posts: 53
In terms of performance I would like to know which map should i go with
1) Collections.synchronizedMap(new HashMap())
2) ConcurrentHashMap()

My application will require multiple threads to access this map frequently
and updates the value corresponding to a key.

The point is if I use the (2) map shall I need to make my get and set methods synchronized that will put and get back the value from HashMap.

If I would go with the first one it definitely needs to be synchronized as the javadoc suggests but using synchronized methods will degrade the performance.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Probably, the ConcurrentHashMap will be faster. Also it offers a richer set of atomic operations, such as putIfAbsent() (which would have required additional synchronization if you tried to do it with a synchronizedMap()).

[nandkishor ra]: The point is if I use the (2) map shall I need to make my get and set methods synchronized that will put and get back the value from HashMap.

No, ConcurrentHashMap is already designed so that get() and put() can be used safely by multiple threads concurrently.

[nandkishor ra]: If I would go with the first one it definitely needs to be synchronized as the javadoc suggests but using synchronized methods will degrade the performance.

I would say it may degrade performance. There are a great many applications where there will be no observable effect at all, because you have a performance bottleneck elsewhere. In general, don't assume that synchronization will be a problem, because it often isn't. Often it's best to just try it and see if the synchronization creates a performance problem or not, rather than making more complex code to avoid a problem that doesn't exist. However in this case, ConcurrentHashMap offers a simple solution that avoids synchronization, and so it's just as easy to not use synchronization as it is to use it. In other cases, if synchronization solves a problem that you can't easily solve another way, don't hesitate to try using synchronization.


"I'm not back." - Bill Harding, Twister
Ashok Mor
Ranch Hand

Joined: Jul 17, 2007
Posts: 44
Hi nandkishor ra,

You must be aware of �collection framework� that it is better to use over any other mechanism for performing operation on collected of objects.

But think is only that collection framework is not synchronized so obviously will perform faster then expected. But we always need to think in direction of multi threading application where we need to have synchronized data to be used.

For that Collection also has facility to use it while the way you talked about, it in this case it is always good to go with legacy classes like �Vector, Hashtable�, because these are also synchronized and faster the other programmatically synchronized collection objects, So I will prefer you to use Hashtable instead of you given options.


Ashok Mor
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Ashok, does your advice apply at all to ConcurrentHashMap? Are you familiar with it at all? It sounds to me like you're just thinking about differences between Collections.synchronizedMap() and Hashtable. You might want to look into the new classes and interfaces added in JDK 5.

Furthermore, I don't agree at all with this statement: "...in this case it is always good to go with legacy classes like �Vector, Hashtable�, because these are also synchronized and faster the other programmatically synchronized collection objects". Even if we ignore ConcurrentHashMap (which is generally faster), saying "always" here is almost certainly wrong. There are many cases where there is no practical difference in performance, as there's a bottleneck elsewhere. There are many other cases where neither Hashtable nor synchronizedMap() is good, because you need to synchronize at a higher level than is provided by those classes.

Additionally, at this point Vector and Hashtable clutter up the API with unnecessary duplicated functionality and poorly-named methods, and the endless litany of beginning programmers unsure whether to use Vector or ArrayList, which usually just wastes people's time when they're worrying about nothing. And worse, the standard answer they receive creates false confidence in people who think they're writing "thread-safe" code just because they're using Vector or Hashtable.

Personally I'd be happier if Vector and Hashtable were removed from Java entirely. Sadly that will probably never happen, as it breaks backwards compatibility for existing programs. But I advocate avoiding them as much as possible, to minimize the problems they entail.
[ July 19, 2007: Message edited by: Jim Yingst ]
nandkishor rao
Ranch Hand

Joined: May 24, 2006
Posts: 53
I didn't get back to you early but thanks for your suggestions.
As suggested i think I can go with concurrent hashmap as also i foud some intereating things about it. It performance get better as concurrent thread tries to access it.I'll share the link with you guys http://codeidol.com/java/java-concurrency/Performance-and-Scalability/.
Take a look.
Thanks
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: concurrent access to HashMap