Java 8+ ConcurrentHashMap锁条
我一直在阅读Brian的Concurency in Practice。
在关于锁条的章节中，ConcurrentHashMap使用16个存储桶来改进多个线程的多线程访问：
锁拆分有时可以扩展到在不同大小的独立对象集上的分区锁定，在这种情况下，它被称为锁条带。例如，ConcurrentHashMap的实现使用一个由16个锁组成的数组，每个锁保护1/16个哈希桶；桶N由锁N 16保护。
我读过这些问题：
需要简单的解释“锁条”如何与ConcurrentHashMap一起工作
然而，这些答案对于<= 7是有效的。
对于Java 8+，这种行为似乎有了很大的改变。对于Java 8+，锁似乎不是为段获取的，而是为特定节点表(transient volatile ConcurrentHashMap.Node<K, V>[] table;)获取的。例如，对于putVal操作：
ConcurrentHashMap.Node var7;
.... ///retrive node for var7
synchronized(var7) {
....
}而且，从Java8 +字段(如DEFAULT_CONCURRENCY_LEVEL和类Segment )，Segment似乎在实现中未使用(它仅在私有方法writeObject::ObjectOutputStream中使用，在ConcurrentHashMap实现中任何地方都不会调用该方法)。
ConcurrentHashMap实现中发生如此重大变化的原因是什么？- 如果类
Segment未使用，而且像DEFAULT_CONCURRENCY_LEVEL这样的字段也未使用--为什么不将其从实现中清除--这是出于历史原因吗？ - 如果我们没有像Java版本< 7那样锁定段，那么仅在特定节点上锁定足够了吗？如果是-为什么？这是不是意味着我们这里不需要锁条纹？
回答 1
Stack Overflow用户
发布于 2019-07-28 10:19:16
ConcurrentHashMap实现中发生如此重大变化的原因是什么？
ConcurrentHashMap.java#l272
* The primary design goal of this hash table is to maintain
* concurrent readability (typically method get(), but also
* iterators and related methods) while minimizing update
* contention.由于兼容性原因，Segment类仍未使用，因此ConcurrentHashMap.java#l481
* Maintaining API and serialization compatibility with previous
* versions of this class introduces several oddities. Mainly:
* [...]
* We also declare an unused "Segment" class that is
* instantiated in minimal form only when serializing...。仅在特定节点上锁定足够吗？如果是-为什么？
ConcurrentHashMap.java#l320
* Using the first node of a list as a lock does not by itself
* suffice though: When a node is locked, any update must first
* validate that it is still the first node after locking it,
* and retry if not.https://stackoverflow.com/questions/57239419
复制相似问题
腾讯云开发者
