• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Bear Bibeault
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • salvin francis
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Jj Roberts

Difference between a concurrent hashmap and a hashmap?

 
Ranch Foreman
Posts: 2076
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I read that for concurrent hashmap multiple threads can access the map at ones without needing to taking the lock.

I know that it is not possible in HashTable since it is synchronized but is this not possible in hashMap ?
Thanks
 
Marshal
Posts: 71098
292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What does the documentation for the two map implementations say? Maybe there is something simple in the Java™ Tutorials.
 
Monica Shiralkar
Ranch Foreman
Posts: 2076
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:What does the documentation for the two map implementations say? [/url].



It says that concurrent hashmap is concurrent and does not block (unlike HashTable ).

I understand that it does not block unlike HashTable and thus gives good performance.

But , these qualities are in hashmap as well.So whats the difference.
 
Campbell Ritchie
Marshal
Posts: 71098
292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You appear not to have read the documentation for HashMap.
 
Monica Shiralkar
Ranch Foreman
Posts: 2076
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Understood the difference between these two that Hashmap is not thread safe and ConcurrentHashmap is thread safe.

However now I am confused between HashMap and ConcurrentHashMap.
HashMap - Faster but not thread safe. Use it when not multiple threads are to access it as same time.
CocurrentHashMap- Thread safe.
Synchronized HashMap- Thread safe. Use it when multiple theads are to access it at same time.

Now I am confused between the second and third.
 
Saloon Keeper
Posts: 12499
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ConcurrentHashMap has atomic operations on individual buckets, so two threads might possibly add two items at the same time without one of them blocking the other. Get operations don't lock the map at all, so a concurrent read and write operation might race against the other. Such a race condition will not lead to inconsistent state however. Bulk operations are not atomic.

A synchronized map has atomic bulk operations, meaning it will completely lock the map if you call a method such as putAll().

If you need a thread-safe map with minimal locking (but possibly outdated reads) use ConcurrentHashMap. If you need a map where every operation is carefully synchronized at the cost of performance, use a synchronized map.
 
Marshal
Posts: 26135
77
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:CocurrentHashMap- Thread safe.
Synchronized HashMap- Thread safe. Use it when multiple theads are to access it at same time.



I just looked at the API documentation for ConcurrentHashMap and the description of the class (just the description, not the list of methods and so on) is about two screens long on my machine. So "Thread safe" may be a good executive summary but it's not sufficient for understanding how it differs from other maps. However the first paragraph might be a useful start:

The documentation wrote:A hash table supporting full concurrency of retrievals and high expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.



You'll notice just from that paragraph that "thread safety" and "synchronization" are not the same thing. The remainder of the description goes into detail about how thread safety is implemented in ConcurrentHashMap.
 
Monica Shiralkar
Ranch Foreman
Posts: 2076
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

If you need a thread-safe map with minimal locking (but possibly outdated reads) use ConcurrentHashMap.



Trying to understand this. What I think is that we either require locking or not require it. When it is to be accessed by multiple threads we can require locking. If we know that threads are not to be accessed by multiple threads then we dont require locking.
 
Paul Clapham
Marshal
Posts: 26135
77
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:What I think is that we either require locking or not require it. When it is to be accessed by multiple threads we can require locking. If we know that threads are not to be accessed by multiple threads then we dont require locking.



If that were the case then you could just have all of the threads synchronize on the whole map and take turns reading from it and updating it. That's one "locking or not locking" scenario. But then that means that one thread can lock the map and spend a lot of time iterating and processing the entire contents of the map while all the other threads wait. And likewise updates to the map would have to be done one at a time, which is perhaps in conflict with the design where many threads are updating the map at the same time. I believe that this is how the Map returned by the synchronizedMap() method works, and the documentation for the method warns about how you have to manually synchronize when you iterate through the "synchronized" map.

So there's a possible design where threads can lock the part of the map they are updating, so that simultaneous updates can often take place. But as you know a map is a complicated thing with many buckets which may be rebuilt from time to time, so "locking part of the map" could be a difficult thing to implement. And then if you do that then iterating the entire map could return results which aren't consistent with how the map looked at any particular time.

In other words it's a complicated business. Which is why the documentation goes into so much detail about what the challenges are and how the class tries to deal with them.
 
Monica Shiralkar
Ranch Foreman
Posts: 2076
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If one knows that the hashmap may be acessed by multiple threads at a time can one go for Concurrent hashmap ? If yes, then when will be go for Hashtable ?
 
Campbell Ritchie
Marshal
Posts: 71098
292
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:. . . when will be go for Hashtable ?

Never. Look on Hashtable as legacy code which nobody uses any more.
 
Monica Shiralkar
Ranch Foreman
Posts: 2076
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Monica Shiralkar wrote:. . . when will be go for Hashtable ?

Never. Look on Hashtable as legacy code which nobody uses any more.



Understood now.So concurrent HashMap does it better what HashTable used to do.
 
reply
    Bookmark Topic Watch Topic
  • New Topic