Re: Hashmap and multiple threads
Hoss Spence wrote:
I inherited some code that uses a Hashmap [sic] being accessed and
Spelling counts.
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 [sic] operations is clearly wrong, it
doesn't explain to me why all threads seemed to be in the containsKey
Luck of the draw. Apparently the users of the HashMap have a usage pattern
involving a lot of 'containsKey()' calls.
() 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).
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?
You cannot get away with synchronizing half the uses. You must synchronize
all of them. You should study multi-threaded programming before you accept a
paycheck for this work. Read /Java Concurrency in Practice/ by Brian Goetz,
et al., and read every IBM DeveloperWorks article by Mr. Goetz before you
begin. "A little knowledge is a dangerous thing."
That you even considered synchronizing only the 'put()' calls indicates that
you don't know what you need to know.
You can wrap the Map in a 'Collections.synchronizedMap()' call if the
synchronization need is simple, or perhaps use a ConcurrentHashMap.
Declare the variable as a 'Map', not as the implementing type.
--
Lew