CODEWITHSUNDEEP
javamultithreading
从此醉
从此醉

Reputation: 117

What are the not thread-Safe cases when using HashMap in Java?

In the API documents, we can see:

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.)

I'm thinking if the "put" method should be synchronized ? It said only the structural modification. Can you give some unsafe cases for the HashMap. And when I view the source code of "HashTable", the "get" method is also been synchronized, why not only the write operations be synchronized?

Upvotes: 1

Views: 369

Answers (3)

Durandal
Durandal

Reputation: 20059

There is a general rule of thumb:

If you have more than one thread accessing a collection and at least one thread modifies the collection at some point, you need to synchronize all accesses to the collection.

If you think about it, its very clear: If a collection is modified while another thread reads from it (e.g. iterates), read and write operation can interfere with each other (the read seeing a partial write, e.g. entry created but value not yet set or entry not properly linked yet).

Exempt from this are collections one thread creates and modifies, then hands of to "the world" but never modifies them after publishing their reference.

Upvotes: 4

Bruno Reis
Bruno Reis

Reputation: 37822

why not only the write operations be synchronized?

If the reads are not synchronized as well, you might encounter visibility issues. Not only that, but it is also possible to completely thrash the object, if it performs structural changes!

The JVM specification gives a few guarantees regarding when modifications to a memory location made by one thread will be visible to other threads. One such guarantee is that modifications by a thread prior to releasing a lock are visible to threads that subsequently acquire the same lock. That's why you need to synchronized the read operations as well, even in the absence of concurrent structural modifications to the object.

Note that this releasing/acquiring locks is not the only way to guarantee visibility of memory modifications, but it's the easiest. Others include order of starting threads, class initialization, reads/writes to memory locations... more sophisticated stuff (and possibly more scalable on a highly concurrent environment, due to a reduced level of contention).

If you don't use any of those other techniques to ensure visibility, then simply locking only on write operations is wrong code. You might or might not encounter visibility issues though -- there's no guarantee that the JVM will fail, but it's possible, so... wrong code.

I'd suggest you read the book "Java Concurrency in Practice", one of the best texts on the subject I've ever read, after the JVM spec itself. Obviously, the book is way easier (still far from trivial!) and more fun to read than the spec...

Upvotes: 1

Artem Moskalev
Artem Moskalev

Reputation: 5818

One example would be:

Thread 1:

Iterator<YourType> it = yourMapInstance.entrySet().iterator();
  while(it.hasNext()) {
    it.next().getValue().doSth();
    Thread.sleep(1000);
  }
}

Thread 2:

for(int i = 0; i < 10; i++) {
  if(Math.random() < 0.5) {
    yourMapInstance.clear();
    Thread.sleep(500);
  }
}

Now, if both threads are executed concurrently, at some point there might be a situation, that you have a value in your iterator, while the other thread has already deleted everything from the map. In this case, synchronization is required.

Upvotes: 1

Related Questions