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

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!

By: Maninder Batth

Maninder Batth — Fri, 29 Aug 2008 14:56:01 +0000

Patrick,
All i can say is i am speechless. I made exact same assumptions as you because, in my application too, the risk of data corruption was managable and easily rectified, hence i choose not to synchronize hashmap and the remainder is the history.
BTW, can you please suggest a cure… I still do not want to synchronize, atleast not externally.

By: Mark L

Mark L — Tue, 19 Aug 2008 04:41:54 +0000

I too assumed that the data was safe, much to my peril!

I am now converting to ConcurrentHashMap. I am assuming this will resolve the issue - has anybody found this not to be the case?

By: Stefan M

Stefan M — Wed, 23 Jul 2008 15:27:53 +0000

“Note that this implementation is not synchronized. If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally.”

I atleast would like to know the why, before someone tells me “You must”. Im grown up and dont want to be treated like a child by these “great programmers”. Im grateful to the author for pointing out the specific problem and hope that all these top down arguers will run into a similar problem themselves.

@MAno “I think data integrity is one of the basic goals when writing ANY kind of real-world application” thats your opinion and you may want to consider that there are other valid opinions out there than just yours.

I agree fully with the author who is not blaming anyone, that the JavaDoc COULD be more verbose than a simple: “you must”.

By: MAno F.

MAno F. — Fri, 04 Jul 2008 15:21:03 +0000

One more note: trying to avoid the consequences of unsynchronized access to HashMap would certainly result in more time spent in get() method (and maybe other methods too), but the reason the HashMap is not synchronized (unlike Hashtable) is exactly: performance.

By: MAno F.

MAno F. — Fri, 04 Jul 2008 15:12:59 +0000

I’m just curious, what kind of application did you wrote, if you did not care about data integrity. I think data integrity is one of the basic goals when writing ANY kind of real-world application (well, except of concurency tests & multithreading-learning/teaching purposes).

As I read the JavaDoc again and again, there was no mention about data integrity. It just says: “if at least one thread makes structural modification, HashMap MUST BE synchronized”. No word about the possible consequences (not only “data integrity”), so this means “ANYTHING COULD HAPPEN, INCLUSIVE THINGS YOU DON’T EXPECT, when you don’t synchronize mutable HashMap accessed from more than one thread”. Inifinite loop is one possible consequence of that.

Well, even the Collection Framework programmers do not know what everything could happen when you don’t keep their warning in mind, so why do they should write down every possible harm the unsynchronized usage of HashMap (accessed from several threads) could cause?

For example - another possible damage I see is losing references to some stored objects when reordering the same linked list concurrently in two or more threads (which is the case this time).

So unless you are just doing harmless experiments, I would suggest YOU ALWAYS SHOULD CARE ABOUT DATA INTEGRITY/CONSISTENCY.

By: Concurrency and HashMap

Concurrency and HashMap — Wed, 02 Jul 2008 13:45:04 +0000

[...] You can read details about the infinite loop problem here. [...]

By: Bakuras

Bakuras — Wed, 02 Jul 2008 09:34:45 +0000

The fact that “you don’t care about integrity of your data” does not mean that you don’t care about if your program will terminate. The problem is that javadoc states explicitly that the behavior of unsynchronized HashMap is UNPREDICTABLE (aka non deterministic) which also means that your program probably will not terminate at all.

If HashMap is used correctly you will get correct behavior, since it is tested by millions and written by great programmers. So complaining about wrong usage of means is really pointless. You know fire have many usages …

If you don’t care about integrity of your data why not to use some random bias if you want simulate non-deterministic behaviors.