Comments on: HashMap.get() can cause an infinite loop!

By: Akku

Akku — Mon, 16 Nov 2009 13:52:54 +0000

Rob,

Thanks for that article. We faced a similar situation in a job which spawned multiple threads, each of which were doing look-up in a HashMap for certain keys. If not found, the key-value was added in the Map for future lookup (Obviously, it should have been synchronized but it was not). Once in a while we would see the threads getting struck at the call to HashMap.get(). After analysing the code, we figured that making it a Hastable was obviously required but we were not sure this could be causing the threads to be struck. (Data consistency, ofcourse, we knew was compromised). Since the conversion to Hashtable, we have not observed the issue. This article helps explain a bit clearly what can lead to the infitine looping.

By: Laurence Vanhelsuwe

Laurence Vanhelsuwe — Fri, 18 Sep 2009 13:20:12 +0000

CollectionSpy lets you see which of your HashMaps are accessed concurrently – ie are at risk of this infinite loop bug. As far as I know, it’s the only Java tool that visualizes this information in an efficient and programmer-friendly manner. See http://www.collectionspy.com for more, including the free download page.

By: Fred Roeber

Fred Roeber — Sat, 05 Sep 2009 15:22:49 +0000

I just ran across this great thread on concurrency issues that’s developed over a couple of years. I’ve been doing concurrent applications for decades but am new to concurrent Java. I did come across an EXCELLENT presentation on the subject in the 200 page chapter on Concurrency in the 4th edition of Thinking in Java. Interestingly, Bruce Eckel (the author) said he got great help from Brian Goetz who chimed in on this thread above in 2005.

From my experience fixing threading problems in the OS code for VMS, Irix, SunOS and VxWorks, no matter how good you are you can never anticipate all the ways threaded code will break. With increasingly complex and common multicore machines, this becomes more true. When documentation says “must” take it as gospel.

This thread was a great read!

By: Ashish

Ashish — Fri, 24 Jul 2009 14:38:31 +0000

Thanks for the wonderful explainations…. Our application will go into infinite loop and have to restrt the server to get it work. so now using ConcurrentHashMap which solves this problem atleast… I wish i was able to nail down this issue few months back then wouldnt had suffer more… lol

Thanks,
Ashish

By: Alain RUSSIER

Alain RUSSIER — Thu, 04 Jun 2009 08:03:30 +0000

Very clear and interesting

By: Concurrency and HashMap

Concurrency and HashMap — Fri, 30 Jan 2009 05:55:31 +0000

[...] Finally i will leave you with this interesting bug in Java which says HashMap can get into infinite loop when used in muti Threaded Environment which further reiterates my point that not all the possible scenarios can be visualized in a multi threaded environment and therefore one should rely on basics rather than trying a smart creativity which has high probability of landing into trouble at some point in future. You can read details about the infinite loop problem here. [...]

By: metatech

metatech — Mon, 01 Dec 2008 13:54:38 +0000

Here is an example stack trace for those like who search Google with it.

“TP-Processor33″ daemon prio=10 tid=0×02591798 nid=0×208 runnable
[0x5ef79000..0×5ef7fa70]
at java.util.LinkedHashMap.transfer(LinkedHashMap.java:231)
at java.util.HashMap.resize(HashMap.java:509)
at java.util.LinkedHashMap.addEntry(LinkedHashMap.java:406)
at java.util.HashMap.put(HashMap.java:431)

I suppose the same can happen for HashMap.transfer or any other flavour.

By: Brian Egge

Brian Egge — Fri, 03 Oct 2008 02:25:34 +0000

A similar, but no less fun, loop can occur within DateFormat. Concurrent use generally leads to garbage in your formatted dates, but can upon occasion cause the DateFormat to get caught in a loop.

If multiple threads access a formatter concurrently, it must be synchronized externally.

I feel the ‘must’ in the JavaDoc is a pretty good warning to say your worst nightmares may come true if you break the rule. Because the implementation of a class is allowed to change, the JavaDoc shouldn’t have to specify exactly what the worst case scenario is. In fact, if you haven’t designed a class with concurrency in mind, it can be really hard to anticipate what the worst case scenario is.

By: Mark L

Mark L — Fri, 29 Aug 2008 20:41:57 +0000

I did convert to ConcurrentHashMap which is in new java.util.concurrent collections. I performed a few tests to check for memory and performance differences of both HashMap and ConcurrentHashMap and they appeared to me to perform roughly about the same.

ConcurrentHashMap sure has solved my problem with this.

Thanks for your original post all them years ago Patrick.

By: plightbo

plightbo — Fri, 29 Aug 2008 14:58:02 +0000

Maninder,
You’ll have to synchronize it. It shouldn’t really cause much of a hit, so just go for it. Or, use the new java.util.concurrent collections and they’ll manage it for you. Good luck!