I had decalred a variable of type HashMap using a static keyword.inside a singleton.
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)
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?
PS: For a reason, I cannot use java concurrency a.k.a ConcurrentHashMap.
"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.
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)