在ConcurrentHashMAP中，为什么最初在Java7中引入HashEntry，为什么在JDK8中删除它？

我试图理解ConcurrentHashMAP（CHM）的实现，但它看起来与CHM的Java 7和Jav8实现有很大的不同

1） 我试图从第一个问题开始理解为什么最初在Java7中引入HashEntry，为什么在JDK8中删除它

2） 以CHM为单位定义表格大小的因素是concurrenylevel还是capacity

/**
 * Stripped-down version of helper class used in previous version,
 * declared for the sake of serialization compatibility
 */
static class Segment<K,V> extends ReentrantLock implements Serializable {
    private static final long serialVersionUID = 2249069246763182397L;
    final float loadFactor;
    Segment(float lf) { this.loadFactor = lf; }
}

/**
*以前版本中使用的helper类的精简版本，
*为了序列化兼容性而声明
*/
静态类段扩展ReentrantLock实现可序列化{
私有静态最终长serialVersionUID=22490692467636182397L；
最终浮动载荷系数；
段（float lf）{this.loadFactor=lf；}
}

3） 并发级别扮演两个角色吗

---

一种是调整表的大小，然后决定可以更新映射的并发线程的数量？ConcurrentyLevel在CHM的内部实现中扮演什么角色，即如何使用此变量值限制线程数量，实现的哪个部分决定了这一点？

您似乎没有完全理解ConcurrentHashMap及其引入背后的意图。它被引入来以最小的锁定完成并发读写操作。使用ConcurrentHashMap，可以同时锁定映射的不同部分。在Java8中，他们使ConcurrentHashMap更加无锁

ConcurrentyLevel在决定ConcurrentHashMap的各种属性值方面起着重要作用

1） 我试图从第一个问题开始理解为什么最初在Java7中引入HashEntry，为什么在JDK8中删除它

回答-您确定它已被删除吗？它可能仍在分段下。请参阅下文-

2） 以CHM为单位定义表格大小的因素是concurrenylevel还是capacity

答案-并发级别决定一切。默认并发级别为16或32。也可以通过编程方式进行设置

3） 并发级别扮演两个角色吗？一种是调整表的大小，然后决定可以更新映射的并发线程的数量

回答-是的。它提供了调整大小的提示。通常，段和并发线程的数量限制在此数量内

ConcurrentyLevel在CHM的内部实现中扮演什么角色，即如何使用此变量值限制线程数，实现的哪个部分规定了这一点

您可以查看oracle文档

供进一步参考—

---

这是公共API的一部分吗（就像在Javadoc中一样）？如果不是，这只是一个实现细节，可以随时更改。我理解实现可能会更改，请尝试理解他们为什么再次更改它？如果你能帮我回答其他的问题，请告诉我。OpenJDK邮件列表可能会包含历史背景。此外，它不是在Java7中“引入”的。Java6中存在

ConcurrentHashMap.HashEntry

类。。。很可能更早。@Stephen C，也许你是对的，我想说明为什么要删除它？我在我的问题部分添加了段类代码以供参考，在那里我看不到任何HashEntry。你能检查一下吗？是的，你是对的，我不完全了解CHM，这就是为什么我想我在这里问问题并寻求帮助：）谢谢你的帮助。