5

I have one doubt. What will happen if I get from map at same time when I am putting to map some data?

What I mean is if map.get() and map.put() are called by two separate processes at the same time. Will get() wait until put() has been executed?

Mureinik
  • 297,002
  • 52
  • 306
  • 350
hatellla
  • 4,796
  • 8
  • 49
  • 101
  • See this link might me this is useful http://stackoverflow.com/questions/2688629/is-a-hashmap-thread-safe-for-different-keys – Rohitesh Jun 29 '15 at 06:52
  • Or this one: http://stackoverflow.com/questions/1361784/hashmap-and-hashtable-in-multithreaded-environment – morpheus05 Jun 29 '15 at 06:53

3 Answers3

5

It depends on which Map implementation you are using.

For example, ConcurrentHashMap supports full concurrency, and get() will not wait for put() to get executed, and stated in the Javadoc :

 * <p> Retrieval operations (including <tt>get</tt>) generally do not
 * block, so may overlap with update operations (including
 * <tt>put</tt> and <tt>remove</tt>). Retrievals reflect the results
 * of the most recently <em>completed</em> update operations holding
 * upon their onset.

Other implementations (such as HashMap) don't support concurrency and shouldn't be used by multiple threads at the same time.

Eran
  • 387,369
  • 54
  • 702
  • 768
  • 2
    "shouldn't be used by multiple threads at the same time" ... without additional synchronization. – Persixty Jun 29 '15 at 07:15
  • 1
    @DanAllen That's true, but since there are standard implementations that already support concurrency, there's less motivation to use the basic classes and add custom synchronization. – Eran Jun 29 '15 at 07:31
  • 1
    I agree except when the map is part of the internal state of some greater object that itself has synchronization round it. Maps are very common both as inside objects and as exposed points of concurrent interaction. – Persixty Jun 29 '15 at 07:57
2

It might throw ConcurrentModificationException- not sure about it. It is always better to use synchronizedMap.This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method.This is best done at creation time, to prevent accidental unsynchronized access to the map:

Map map = Collections.synchronizedMap(new HashMap(...));
Ashish Shetkar
  • 1,414
  • 2
  • 18
  • 35
1

Map is an interface, so the answer depends on the implementation you're using.

Generally speaking, the simpler implementations of this interface, such as HashMap and TreeMap are not thread safe. If you don't have some synchronization built around them, concurrently puting and geting will result in an undefined behavior - you may get the new value, you may get the old one, bust most probably you'd just get a ConcurrentModificationException, or something worse.

If you want to handle the same Map from different threads, either use one of the implementations of a ConcurrentMap (e.g., a ConcurrentHashMap), which guarantees a happens-before-sequence (i.e., if the get was fired before the put, you'd get the old value, even if the put is ongoing, and vise-versa), or synchronize the Map's access (e.g., by calling Collections#synchronizedMap(Map).

Mureinik
  • 297,002
  • 52
  • 306
  • 350