Could the static keyword cause a bottleneck/ deadlock?

[Jeevan Sunkersett]

Hi,

I had decalred a variable of type HashMap using a static keyword.inside a singleton.

public class MySingletonClass {
private static HashMap<String, MetaInfoTO> metaInfoXML = null;
public init() {
//the hashMap is intialized and filled up in this method,
// NOTE, this is invoked only once in the application lifecycle (ie. during intialization)
// and so the put() funtion on this hash map is called only here.
}
private MySingletonClass() {
}
public MySingletonClass getInstance() {
//standard block of code for the singleton pattern;
// if instance exists return it or create the new instance ...and return;
}
public HashMap<String, MetaInfoTO> getMetaInfoMap() {
return metaInfoXML;
}
}

Once intialized multiple threads could be launched inside my application; and each thread was doing a get() on the hashMap for a different key (as was determined by the executing logic)

public class MyThread extends Thread {
pubclic void run()
{
// some code
// ...
MySingletonClass.getInsatnce().getMetaInfoMap().get(key);
// ... do something
}
}

But I observed, that the multiple threads in my application soon become un-responsive..... sort of deadlocked.
The rest of the application is not affected, but the core feature (implemented in the threads) stops functioning.

I think a HashMap is safe to use in the above acenario as the multiple threads are not modifying it and only getting from it.

Could the 'static' keyword or the 'singleton' nature of the enclosing class be a culprit?

~g1

PS: For a reason, I cannot use java concurrency a.k.a ConcurrentHashMap.

[Adam Smolnik]

I've found a description of some problem with (maybe) similar symptoms:
Please, take a look at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457

Especially, pay attention to:

Doug Lea writes:

"This is a classic symptom of an incorrectly synchronized use of
HashMap. Clearly, the submitters need to use a thread-safe
HashMap. If they upgraded to Java 5, they could just use
ConcurrentHashMap. If they can't do this yet, they can use
either the pre-JSR166 version, or better, the unofficial backport
as mentioned by Martin. If they can't do any of these, they can
use Hashtable or synchhronizedMap wrappers, and live with poorer
performance. In any case, it's not a JDK or JVM bug."

I agree that the presence of a corrupted data structure alone
does not indicate a bug in the JDK.

Adam

[Andrei Matyas]

Hello,

1) If you need to cache something at the singleton level why is your map declared static (anyway you should have only one class instance - singleton).
2) The singleton pattern it's not well implemented and it is not thread safe. Please review your singleton implementation using a static init or using a ThradLocal + double checked lock.
In your case I bet that multiple class instances are created (no singleton) and every instance write/read in your static map. Using a HashMap in a multithreaded environment will create deadlock (cycles on its internal structures)

[abhay bansal]

I guess there is no room for a deadlock here.

package SingletonHashMap;
import java.util.HashMap;
public class Test
{
private static HashMap<String, String> metaInfoXML = new HashMap<String, String>();
private static Test test = new Test();
public void init() {
for(int i = 0;i<10;i++)
metaInfoXML.put("key"+i, "value"+i);
}
private Test() {
init();
}
public static Test getInstance() {
return test;
}
public HashMap<String, String> getMetaInfoMap() {
return metaInfoXML;
}
}

package SingletonHashMap;
import java.util.Random;
public class TestThreading implements Runnable
{
public void run()
{
System.out.println(Test.getInstance().getMetaInfoMap().get("key"+new Random().nextInt(10)));
}
public static void main(String[] args)
{
for(int i =0;i<10;i++)
new Thread(new TestThreading()).start();
}
}

This works fine. No matter how many times you run it.