• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

synchroniztion of map

 
Shanky Sohar
Ranch Hand
Posts: 1051
Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the case of multithreading,,, we have four option for a map to use...

Can anybody Know which one to consider so that we can have a better performance/////

1...
Use hashmap()
Map map = new HashMap();
and synchronize all the methods where are using hashmap

2..
Synchronized the hashMap using Collections class static utility method synchronizedMap(..);
Like Map map = Collections.synchornizedMap(new HashMap());


3. use ConcurrentHashMap();

4.HashTable()..as it already have all the method as synchronized....

Which one will give better performance...

As per what i think...concurrentHashMap() will win among all the four ways...



 
Winston Gutkowski
Bartender
Pie
Posts: 10527
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shanky Sohar wrote:As per what i think...concurrentHashMap() will win among all the four ways...

Well it was designed specifically with concurrency in mind, so it seems like a reasonable guess; but the only real way to know is to test it.

Winston
 
chander shivdasani
Ranch Hand
Posts: 206
Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ConcurrentHashMap is the way to go.

Prior to Java 5, the only way to concurrently access a HashMap was to synchronize the entire map. In case of high contention, this solution would fail as most of the threads would be waiting for other thread to release the lock on Map. Java 5 brings ConcurrentHashMap, in which only a part of the Map is locked, such that many threads can access different parts simultaneously. This optimization is possible, since HashMap stores their data in buckets. This optimization is known as lock striping.

 
Winston Gutkowski
Bartender
Pie
Posts: 10527
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chander shivdasani wrote:ConcurrentHashMap is the way to go...

I don't think you can say that categorically, because it will depend a lot on Shanky's pattern of use. ConcurrentSkipListMap, for example, is supposedly faster than a synchronized TreeMap under multitasking load, but it's quite a bit slower under normal (ie, uncontested) use; and where the 'crossover' comes can only be determined by testing.

I suspect that all you can definitely say is that the performance of ConcurrentHashMap is likely to scale better as load increases, because that's what it was designed for. The class can also be tuned for expected numbers of 'writers'; HashMap can't.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chander shivdasani wrote:ConcurrentHashMap is the way to go.

Prior to Java 5, the only way to concurrently access a HashMap was to synchronize the entire map. In case of high contention, this solution would fail as most of the threads would be waiting for other thread to release the lock on Map.


This claim also cannot be made without knowing a lot more about the OP's requirements, operating environment, and usage pattern. Lots of multithreaded programs used this approach successfully for over about a decade before Java 5 came along.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shanky Sohar wrote:In the case of multithreading,,, we have four option for a map to use...

Can anybody Know which one to consider so that we can have a better performance/////

1. No, we can't without knowing more details about your situation, and probably not without testing your actual code in your actual environment with your actual usage patterns.

2. There's a fair chance that you won't be able to tell the difference among any of those approaches.

Unless you have a specific, measurable reason to know that some of them will fail to meet your performance requirements and others will succeed, the correct approach is to use the one that's easiest to use--that fits in best with your design, is easiest to write, test, debug and maintain--and then test its performance. If it's good enough for your current and expected future needs, then, by definition, there's no benefit to making it any faster.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic