Concurrency and HashMap

June 29, 2008

Author: Pavitar Singh

In theory everyone knows Hash Map is not Thread Safe and it shouldn’t be used in multi Threaded applications. But still people come out with their own theories that they can use HashMap in their context. Some say they are just reading the data and map is not written to a lot. Unfortunately none of these explanations holds good when one lands up in a synchronization issue. Normally most of the guys do not understand fundamentals around Java Memory Model and Concurrency .One cannot blame them for not knowing their fundamentals as its hard for people to visualize concurrent executions since from college days we are used to sequential executions of program.

Enuf of blame game, now lets look into some code.Have a look at the code mentioned below and come out with all your theories of what can go wrong with it or theories which say its all correct.

public class MapTestTask implements Runnable {

private Map hashMap;

private Object      value = new Object();

public MapTestTask(Map map) {
  this.hashMap = map;
}

public void run() {
  hashMap.put(Thread.currentThread(), value);
  Object retrieved = hashMap.get(Thread.currentThread());
   if (retrieved == null) {
  // Can it ever Happen
  }
}
}

Now question is when we run multiple such Threads can we ever see retrieved as null.

If we look from sequential point of view it can never happen.But when concurrency comes into picture this can happen. I will give you a code with which can reproduce this scenario.

This is my sincere advise : do not over engineer when Concurreny is involved. Because none of the theories will stand the test of time in a concurrent environment. As a rule of thumb use Thread safe collections wherever concurrency is involved.

Finally i will leave you with this interesting bug in Java which says HashMap can get into infinite loop when used in muti Threaded Environment which further reiterates my point that not all the possible scenarios can be visualized in a multi threaded environment and therefore one should rely on basics rather than trying a smart creativity which has high probability of landing into trouble at some point in future.
You can read details about the infinite loop problem here.

Source Code for Reproducing:
MapTestTask.java

package test;

import java.util.Map;

public class MapTestTask implements Runnable {

    private Map hashMap;

    private Object      value = new Object();

    public MapTestTask(Map map) {
        this.hashMap = map;
    }

    public void run() {
                hashMap.put(Thread.currentThread(), value);
                Object retrieved = hashMap.get(Thread.currentThread());
                if (retrieved == null) {
                    // Can it ever Happen
                    System.out.println("Oh My God it can happen.");
                }

            }
}

TestMap.java

package test;

import java.util.Map;
import java.util.HashMap;

public class TestMap {

    public static void main(String[] args) throws InterruptedException {

        Map map = new HashMap();

        int NUM_THREADS = 1000;
        Thread[] threads = new Thread[NUM_THREADS];
        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i] = new Thread(new MapTestTask(map));
        }

        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i].start();
        }

        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i].join();
        }
    }

}

Entry Filed under: Concurrency. .

4 Comments Add your own

  • 1. James  |  June 30, 2008 at 6:20 am

    Nice, well explained article. I think this could do really well on JavaLobby. If you’re interested in reposting there, send me a mail and we can organise it

    James

    Reply
  • 2. dj  |  July 1, 2008 at 4:34 am

    Nicely written. But I was not able to reproduce it. any clues ?

    Reply
  • 3. Michael B  |  July 1, 2008 at 9:49 pm

    “Finally i will leave you with this interesting bug in Java which says HashMap can…”
    Wrong choice of words as it’s not a bug. A pitfall for the uninitiated? sure.

    not thread-safe means not thread-safe. It’s a visibility issue that is goign to stay in there as it’s outside the scope of what a hashmap is suppose to do, use a ConcurrentMap implementation.

    For an other perfect example where ppl also used there ’smart creativity’ check out:
    http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

    dj wrote:
    “Nicely written. But I was not able to reproduce it. any clues ?”
    Try reading this blog: http://java.dzone.com/articles/but-it-works-on-my-machine
    In short the jvm you used might provide more visibility that it has too. The bottom line that which isn’t guaranteed to work is going to bit you in the ass -> small adaptation of murphies law.

    Reply
  • 4. Rahul  |  April 7, 2009 at 8:37 am

    I dont think the rule of thumb “use Thread safe collections
    wherever concurrency is involved” is much of a use.
    Consider you want to use HashTable instead of HashMap, when concurrency is required. As far as i know, only the individual methods in HashTable are synchronized, there is nothing that prevents Thread T2 from changing that HashTable, when thread T1 has come out of one method, say put() and is still to enter into get().
    So, where concurrency is important, it is important to write code that takes care of it, instead of using Thread safe collections(which are obviously better than non thread safe collections, like HashMap in this case)

    Reply

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Training @ Affordable Prices

We offer in-depth training on Spring,Hibernate,jQuery,ExtJs and JSF for just 500 USD each course.Training is delivered using WebEx. training@webscale.co.in

Blog Stats

Top Posts

Feeds