CODEWITHSUNDEEP
javamultithreadingcollections
user1010434
user1010434

Reputation: 241

Is this case not need to lock when there are only 1 writer and N reader?

HashMap is not thread safe.

In my case: 1 writer thread to update the HashMap, and N reader thread to read from the HashMap.

I found tha there is only 1 bad case :

  1. reader N read a value V1
  2. writer update V1 to V2
  3. reader N use value V1(but it is V2 now )

if in my business , we can tolerate this case, is there any other bad case?

Upvotes: 2

Views: 85

Answers (5)

BartoszKP
BartoszKP

Reputation: 35901

A more severe problem can occur if a reader will iterate over the HashMap and simultaneously it will be modified by the writer. Usually modification of such collection (in other languages like C# or Python) invalidates all its iterators.

From the documentation:

Note that this implementation is not synchronized. If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.)

Upvotes: 4

AKS
AKS

Reputation: 1423

Well, If you are asking what all could happen in this case, then first thing we should understand is that when a class is documented as NOT THREAD SAFE, then all those bad things can happen which generally happens with non-thread safe classes. Now what happens with non-thread safe classes, it will not behave correctly as per it's contract. That means if you call get(Key) , it might not return correct value. And such behavior of Non-Thread safe classes are attributed to ATOMICITY and VISIBILTY.

Bottom line is that if a class is not thread safe, you can't count on it's contracts or exposed features.

Upvotes: 0

josefx
josefx

Reputation: 15656

The writer can modify the internal structure of the HashMap while a reader searches in it, resulting in random behavior (wrong values, null instead of a value, exceptions). Also the changes might never propagate to other threads without anything telling the jvm to expect multithreaded access, updates are never synchronized over multiple cpu cores or the jvm just optimizes them out as noop.

In your case you can use a ReadWriteLock to ensure that all readers can access the map concurrently while the writer has exclusive access.

Upvotes: 0

Trying
Trying

Reputation: 14278

There are two problems without proper synchronization. One is visibility andatomicity`. suppose you have map and in one thread you are incrementing the value. than it may be possible the other thread will see a stale value. Similarly if one thread has already put K, V, it may be possible the other thread may not see it. Similarly iteration will also suffer.

So for safe publication , visibility problem better to use ConcurrentHashMap which uses lock striping for better concurrency. But for the increment stuff that i have mentioned above we need to use external synchronization.

The best thing that we can do if we are not changing the value(K) or key (K) and we just inserting to /getting from the HashMap then make key and value class as immutable class. And importantly declare HashMap as final. This will take care of happens before relation and problems will go away. Thanks.

Upvotes: 1

Tony Ennis
Tony Ennis

Reputation: 12299

The case you mention is not really an issue since the same thing could happen if HashMap were thread-safe. Where you can have trouble is if V2 reads from the HashMap while V1 is in the process of making a change. At that time, the HashMap's internal state is inconsistent. This can cause V2's program to crash mysteriously, without apparent reason.

Upvotes: 1

Related Questions