Re: Hashmap and multiple threads
Hoss Spence wrote:
Hi,
I inherited some code that uses a Hashmap being accessed and
updated by multiple threads in a completely unprotected
(unsynchronized) manner. I discovered this after looking at a JBOSS
thread dump that showed all ten threads in this state.
JBOSS Thread Dump
Thread: JMS SessionPool Worker-68 : priority:5, demon:true, threadId:
1786, threadState:RUNNABLE, threadLockName:null
java.util.HashMap.containsKey(Unknown Source)
com.ingenix.freya.rulesengine.ListServiceSingleton.getListTypeByName
(ListServiceSingleton.java:77)
com.ingenix.freya.rulesengine.RulesKBServiceImpl.getListTypeByName
(RulesKBServiceImpl.java:2884)
Although not protecting the Hashmap operations is clearly wrong, it
doesn't explain to me why all threads seemed to be in the containsKey
() call. Does anyone have any ideas? This is hard to duplicate (as
you'd expect a problem with using a non synchronized Hashmap accessed
by multiple threads would be).
A HashMap has a linked list associated with each bucket. It works by
using the hash code to select a bucket, then scanning the linked list.
Given unsynchronized puts and removes by multiple threads, one of those
linked lists could have become a loop, so that any thread scanning it
and not finding what it is looking for will continue to search it until
killed.
In effect, a non-finding scan of a particular bucket will capture the
thread doing it, and keep it in the scan for ever. Threads will go on
being captured, with a corresponding reduction in performance, until all
your worker threads are in a CPU-bound loop scanning the list, and the
application completely stops working.
Many HashMap operations scan the list. If most list scans that fail to
find are from containsKey, it could just be luck of the draw. It might
be interesting to check the frequency of containsKey calls compared to
e.g. put calls for a key that is not present.
Also I had originally thought to fix this by synchronizing just around
the "put" but now am wondering if this should be done at the "get()"
and "containsKey()" code as well. Any thoughts on this?
I would *not* do selective synchronization. It could leave you with
flakiness that is even harder to reproduce and deal with than your
current problem. It might prevent the lists from becoming permanently
broken, but still cause a e.g. a get call to fail to find an entry that
really is there, because it scanned a list while it was being modified
by another thread.
Patricia