Why there is no ConcurrentLinkedHashMap class in jdk?

Question

This question follows directly from my previous question here in SO . I think the answer to my second question is no . So I would like understand why there is no ConcurrentLinkedHashMap in java.util.concurrent package ? I mean there is a ConcurrentHashMap but no ConcurrentLinkedHashMap . Does it not make any sense at all to have such a class in Concurrent environments ? I mean what is the main technical reason here for its non availabalility ? Is there something similar in Guava/ Apache Commons ?

Solution 1

Why there is no ConcurrentLinkedHashMap class in jdk?

You would need to ask the Oracle Java guys that, but I imagine that it is a combination of:

• a perception that not many people would need it, and
• the inherent difficulties in implementing data structures with good performance properties in highly concurrent use cases.

In this case, it seems to me that implementing the collection class so that iterating the key/value/entry sets is not a concurrency bottleneck would be ... um ... difficult. (And even if people have figured a way to do it, the fact remains that designing and implementing and proving the correctness of general purpose highly concurrent data structures and algorithms is hard.)

Solution 2

Looks like there is one from Google https://code.google.com/p/concurrentlinkedhashmap/

Check also this post: What does it mean that ConcurrentLinkedHashMap has been integrated into Guava?

Comments

[Geek]

@mre I am not whining about it at all , just asking to find out if there is any technical reason here why it is not available .

[Louis Wasserman]

Maintaining the linked list structure correctly in a concurrent environment is extremely difficult, if it's possible at all. That's the problem.

[Stephen C]

The reason that the ConcurrentXxx collection types exist is to give good performance when operations on the collection are contended. The synchronized wrappers do not have this property. And for the record, the wrapper classes existed long before the Concurrent collections ... check the "Since:" tags in the respective javadocs.

[UmNyobe]

I agree. That's one of the reason I mentioned to be sound.

[Stephen C]

"From a design point of view, it makes more sense to always have to use ...". Nonsense. From a design perspective it ONLY makes sense to use a data structure that is going to give you the required performance characteristics. A "nice" or "elegant" or whatever design that doesn't give a workable implementation is an incorrect design.

[UmNyobe]

well you can also have ConcurrentAtomicHashMap, ConcurrentSafeHashMap, ConcurrentLinkedList,ConcurrentNonBlockingLinkedList,Concurr‌​entArrayList etc... an optimized class for every variation of concurrency and every type of existing collection you want. Just that this number explodes.

[Ben Manes]

Perception depended on which features of LHM were of interest. The FIFO iteration could easily be emulated by CSLM or a decorated CHM. The LRU bounded size was difficult do concurrently until the Google Code project demonstrated an algorithm (now in Guava's Cache). LHM's api for caching also poses challenges so it cannot be emulated.

[yonil]

Data structure capabilities are not something you design in a decoupled way, it just doesn't work that way. Annotations/augmentations have to be actively maintained, some techniques interfere with one another. On top of that, all the small details have to be considered when attempting to provide invariants under concurrent access, if synchronization happens in a finer granularity than that of an external lock.

[Stephen C]

Well perhaps the author of the Caffeine library should consider donating his code to OpenJDK :-)

[Ben Manes]

I think Doug sees it as too complex a problem that he's not particularly interested in (compared to ForkJoinPool which is insane and great). I'd love to see what he'd do if he ever got the itch, but I bet he's more interested in retiring these days.