Re: Hashmap and multiple threads
Patricia Shanahan wrote:
Hoss Spence wrote:
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
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
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.
Another thought, depending on how your application is driven. Suppose
there is some transaction that requires a containsKey call that is going
to go into a loop because of a broken linked list. That transaction is
given to one thread, which gets captured, and fails to respond. After
some time-out, the transaction is resubmitted, picked up by a different
worker thread, which does the containsKey call and gets captured. That
continues, until all worker threads are attempting the same, impossible
to complete, operation.
Note that HashMap, in order to perform better than LinkedList, needs
most of its operations to not access any given bucket. Threads go on
working normally until they access the bucket with the broken list, and
there may be only the one transaction that needs to do that access, and
its first access to the bucket is a containsKey call.