简体   繁体   English

为什么concurrentHashMap需要一个Segment数组? 为什么它无法在节点上获得锁定?

[英]Why does concurrentHashMap need an array of Segment? Why cant it acquire lock on node?

I was reading this article to understand how ConcurrentHashMap worked internally. 我正在阅读这篇文章,以了解ConcurrentHashMap如何在内部工作。 https://dzone.com/articles/how-concurrenthashmap-works-internally-in-java https://dzone.com/articles/how-concurrenthashmap-works-internally-in-java

But I do not understand use of Segments here. 但我不明白在这里使用Segments。 It is public final Segment[] segments = new Segment[32] in this article. 它是本文中的公共最终Segment [] segments = new Segment [32] Before i read this article, my understanding was there would be multiple Entry tables & each segment would hold reference of one array of the multiple.But in this article there is only one 在我阅读本文之前,我的理解是会有多个Entry表,每个段都会保存多个数组的一个数组的引用。但在本文中只有一个

 protected transient Entry[] table; 

My question - 我的问题 -

1) Will this above single array " table " hold entry for all the segments ? 1)上面的单个数组“ ”是否会保留所有段的条目? Meaning - If I put 2 entries in ConcurrentHashMap,which would return 2 different segments, would it still go under same entry table above? 含义 - 如果我在ConcurrentHashMap中放入2个条目,它将返回2个不同的段,它是否仍然位于上面的相同条目表下? I am confused why aren't there multiple arrays for each segment defined above? 我很困惑为什么上面定义的每个段没有多个数组?

2) Instead of using segment and locking it, when cant a lock be acquired Entry object and perform write/update ? 2)不能使用段并锁定它,当一个锁不能获得Entry对象并执行写/更新?

Will this above single array "table" hold entries for all the segments? 上面的单个数组“表”是否包含所有段的条目?

Yes. 是。

I am confused why aren't there multiple arrays for each segment defined above? 我很困惑为什么上面定义的每个段没有多个数组?

Because, the Segment objects really serve as locks for segments of the main entries array. 因为, Segment对象实际上充当主entries数组的段的锁。 The segments are conceptual "slices" of the main array. 段是主阵列的概念“切片”。

Instead of using segment and locking it, when cant a lock be acquired Entry object and perform write/update ? 而不是使用段并锁定它,当一个锁不能获得Entry对象并执行写/更新?

An operation that updates the ConcurrentHashMap will typically read and write the main entries array. 更新ConcurrentHashMap的操作通常会读取和写入主entries数组。 Simply locking one Entry is not sufficient to perform table insertions and deletions safely. 简单地锁定一个Entry不足以安全地执行表插入和删除。


If the descriptions in that article are confusing, you could also look at the source code directly; 如果该文章中的描述令人困惑,您还可以直接查看源代码; eg http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/concurrent/ConcurrentHashMap.java/ 例如http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/concurrent/ConcurrentHashMap.java/

there are no array of segments in concurrenthashmap since java 8 onward. 自java 8以后,concurrenthashmap中没有任何段数组。 it directly has array of Node 它直接有Node数组

Java 8 onward there is no segment array, lock is acquired on the first node of the LinkedList of a particular hashed index/bucket of the internal hash table array. Java 8以后没有段数组,在内部哈希表数组的特定散列索引/存储桶的LinkedList的第一个节点上获取锁 ConcurrentHashMap internal ConcurrentHashMap内部

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 为什么我们需要锁定 Hashtable/ConcurrentHashMap 的 put 方法? - Why do we need lock in the put methods of Hashtable/ConcurrentHashMap? Reentrantlock-为什么我们需要多次获取锁? - Reentrantlock - Why do we need to acquire a lock multiple times? 为什么递归获取(可重入)锁? - Why acquire a (reentrant) lock recursively? 为什么要在释放操作中获取锁 - Why acquire a lock in a release operation 为什么ConcurrentHashMap.Segment和ConcurrentHashMap.HashEntry类是静态的? - Why ConcurrentHashMap.Segment and ConcurrentHashMap.HashEntry classes are static? 为什么 ConcurrentHashMap 不能为每个桶都加锁? - Why ConcurrentHashMap cannot have a lock for each bucket? 在ConcurrentHashMap中,为什么不在段上使用ReentrantReadWriteLock代替ReentrantLock - In ConcurrentHashMap, why don't use ReentrantReadWriteLock in place of ReentrantLock on segment 为什么ConcurrentHashMap在双重检查锁定中起作用 - Why does ConcurrentHashMap work in Double Checked Locking 为什么TreeBin在ConcurrentHashMap中保持读写锁定? - why TreeBin maintains a read-write lock in ConcurrentHashMap? 为什么HashMap(JDK1.8)中的hash计算不需要像ConcurrentHashMap那样考虑负hashCode? - Why the calculation of hash in HashMap(JDK1.8) don't need to consider the negative hashCode as ConcurrentHashMap does?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM