为什么jdk中没有ConcurrentLinkedHashMap类？答案

【问题标题】：Why there is no ConcurrentLinkedHashMap class in jdk?为什么jdk中没有ConcurrentLinkedHashMap类？
【发布时间】：2012-09-06 12:26:27
【问题描述】：

这个问题直接跟在from my previous question here in SO 后面。我认为我的第二个问题的答案是否定的。所以我想了解为什么 java.util.concurrent 包中没有 ConcurrentLinkedHashMap ？我的意思是有一个 ConcurrentHashMap 但没有 ConcurrentLinkedHashMap 。在并发环境中拥有这样一个类根本没有任何意义吗？我的意思是它不可用的主要技术原因是什么？ Guava/Apache Commons 中有类似的东西吗？

【问题讨论】：

@mre 我根本没有抱怨它，只是想看看这里是否有任何技术原因导致它不可用。
在并发环境中正确维护链表结构是极其困难的，如果可能的话。这就是问题所在。

标签： java data-structures java.util.concurrent

【解决方案1】：

为什么jdk中没有ConcurrentLinkedHashMap类？

您需要询问 Oracle Java 人员，但我想这是以下几种情况的结合：

认为没有多少人需要它，并且
在高并发用例中实现具有良好性能属性的数据结构的固有困难。

在这种情况下，在我看来，实现集合类以便迭代键/值/条目集不是并发瓶颈......嗯......困难。（即使人们已经想出了办法，但事实仍然是，设计、实现和证明通用高度并发数据结构和算法的正确性是困难的。）

【讨论】：

感知取决于感兴趣的 LHM 的哪些特征。 CSLM 或修饰的 CHM 可以轻松地模拟 FIFO 迭代。在 Google Code 项目展示了一种算法（现在在 Guava 的缓存中）之前，LRU 有界大小很难同时进行。 LHM 的缓存 api 也带来了挑战，因此无法模拟。
也许 Caffeine 库的作者应该考虑将他的代码捐赠给 OpenJDK :-)
我认为 Doug 认为这是一个他并不特别感兴趣的过于复杂的问题（与疯狂而伟大的 ForkJoinPool 相比）。我很想看看他如果痒了会怎么做，但我敢打赌他最近对退休更感兴趣。

【解决方案2】：

好像有一个来自 Google https://code.google.com/p/concurrentlinkedhashmap/

还请查看此帖子： What does it mean that ConcurrentLinkedHashMap has been integrated into Guava?

【讨论】：

【解决方案3】：

#define PERSONAL_OPINION

从设计的角度来看，总是必须使用更有意义

Map m = Collections.synchronizedMap(new HashMap());
  ...
Set s = m.keySet();  // Needn't be in synchronized block
  ...
synchronized(m) {  // Synchronizing on m, not s!
   Iterator i = s.iterator(); // Must be in synchronized block
   while (i.hasNext())
      foo(i.next());
}

synchronizedMap 中的示例

为什么？因为同步机制与高度抽象（Map 接口）相关联。但假设我是对的，仍然有ConcurrentHashMap 的原因可能有两个：

ConcurrentHashMap 在此同步机制之前存在
创建特定的同步机制可以提高性能。

我的观点是在理想的设计世界中，即使ConcurrentHashMap 也不应该存在。

#end //personal opinion

【讨论】：

存在 ConcurrentXxx 集合类型的原因是为了在对集合的操作竞争时提供良好的性能。同步包装器没有此属性。并且作为记录，包装类在 Concurrent 集合之前很久就存在了......检查相应 javadocs 中的“Since:”标签。
我同意。这就是我提到的健全的原因之一。
“从设计的角度来看，总是必须使用 ...”。废话。从设计的角度来看，只有使用能够为您提供所需性能特征的数据结构才有意义。 “不错”或“优雅”或任何不能提供可行实现的设计都是不正确的设计。
你也可以有ConcurrentAtomicHashMap, ConcurrentSafeHashMap, ConcurrentLinkedList,ConcurrentNonBlockingLinkedList,ConcurrentArrayList 等等...一个针对每一种并发变化和每一种现有集合类型的优化类你要。只是这个数字爆炸了。
数据结构功能不是您以解耦方式设计的，它只是不能那样工作。注释/增强必须积极维护，一些技术会相互干扰。最重要的是，如果同步发生在比外部锁更细的粒度上，则在尝试提供并发访问下的不变量时，必须考虑所有小细节。