Java 为什么jdk中没有ConcurrentLinkedHashMap类？

这个问题直接引出。我想第二个问题的答案是否定的。所以我想了解为什么java.util.concurrent包中没有ConcurrentLinkedHashMap？我的意思是有一个ConcurrentHashMap，但没有ConcurrentLinkedHashMap。在并发环境中拥有这样一个类毫无意义吗？我的意思是，它不可用的主要技术原因是什么？番石榴/阿帕奇公地里有类似的东西吗

为什么jdk中没有ConcurrentLinkedHashMap类

您需要询问Oracle Java人员，但我认为这是以下因素的组合：

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

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

从设计的角度来看，总是使用

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());
}

举例

为什么?？因为同步机制与高度抽象（

Map

接口）相关联。但假设我是对的，那么仍然有两个理由可以使用

ConcurrentHashMap

：

• 此同步机制之前存在

  ConcurrentHashMap

• 创建特定的同步机制会提高性能

我的观点是在理想的设计世界中，即使

ConcurrentHashMap

不应该存在

#end //personal opinion

---

看起来有一个来自谷歌

也请查看此帖子：

---

@mre我一点也不抱怨它，只是想了解它不可用的技术原因。如果可能的话，在并发环境中正确维护链表结构是极其困难的。这就是问题所在。ConcurrentXxx集合类型存在的原因是为了在集合上的操作被争用时提供良好的性能。同步包装器没有此属性。记录在案，包装类早在并发集合之前就存在了。。。检查各个javadocs中的“自：”标记。我同意。这就是我提到“声音”的原因之一。“从设计的角度来看，总是使用……”更有意义。胡说从设计的角度来看，只有使用能够提供所需性能特征的数据结构才有意义。“好的”或“优雅的”或任何不能提供可行实现的设计都是不正确的设计。你也可以有

ConcurrentAtomicHashMap

，

ConcurrentSafeHashMap

，

ConcurrentLinkedList

，

ConcurrentNonBlockingLinkedList

，

ConcurrentArrayList

等。。。一个优化的类，用于并发的每一种变化和您想要的每种类型的现有集合。数据结构功能不是以解耦的方式设计的，它就是不能以这种方式工作。注释/扩充必须积极维护，有些技术相互干扰。除此之外，如果同步发生的粒度比外部锁的粒度更细，那么在尝试在并发访问下提供不变量时，必须考虑所有的小细节。感知取决于LHM的哪些特性是感兴趣的。FIFO迭代可以很容易地由CSLM或修饰的CHM模拟。在Google代码项目演示了一种算法（现在在Guava的缓存中）之前，很难同时实现LRU边界大小。LHM的缓存API也带来了挑战，所以它不能被模仿。也许咖啡因文库的作者应该考虑将他的代码捐赠给OpenJDK：-）我认为道格认为这是一个他不特别感兴趣的问题，太复杂了（与<代码> FokCouthPoopy<代码>相比，这太疯狂了，太棒了）。我很想看看如果他发痒的话会怎么做，但我打赌他现在对退休更感兴趣。

#end //personal opinion