concurrenthashmap 中的可重入锁是否使用它的可选“公平”参数？答案

【问题标题】：Does reentrant lock in concurrenthashmap uses it's optional “fairness” parameter?concurrenthashmap 中的可重入锁是否使用它的可选“公平”参数？
【发布时间】：2013-07-09 05:12:16
【问题描述】：

在 ConcurrentHashMap 中，我们有基本上扩展 ReentrantLock 的段。

static final class Segment<K,V> extends ReentrantLock implements Serializable

这个 ReentrantLock 是否使用它的公平属性？

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

假设线程 t1 在 ConcurrentHashMap 的一个分区上具有读锁，另外两个线程 t2 和 t3 分别在同一分区上等待读锁和写锁。那么一旦 t1 释放它的锁，哪个（t2 或 t3）将获得锁。

据我所知，如果将公平设置为真，那将是等待时间最长的人。但是在concurrentHashMap的情况下是否设置为true？如果不是，我们可以肯定地说哪个线程会获得下一个锁？

【问题讨论】：

据我所知，ConcurrentHashMap 不会锁定读取。
是的，它没有，除了少数小情况。我的观点是这不会导致数据不正确吗？假设我们执行 putAll() 操作，然后执行读取操作。 putAll() 的所有更改是否会反映在另一个线程的后续读取中？

标签： java synchronization concurrenthashmap

【解决方案1】：

从 ConcurrentHashMap 源码中我们可以看到它使用了 ReentrantLock 的子类

static final class Segment<K,V> extends ReentrantLock
   ...
   Segment(float lf, int threshold, HashEntry<K,V>[] tab) {
            this.loadFactor = lf;
            this.threshold = threshold;
            this.table = tab;
   }
   ...

正如我们所见，它唯一的构造函数隐式调用了 ReentrantLock 的无参数构造函数，该构造函数创建了一个非公平锁。这意味着 ConcurrentHashMap 的锁总是不公平的

【讨论】：

那么有什么顺序或确定性可以断言下一个线程将获得锁吗？
没有。但是，如果我们选择适当的并发级别，则根据文档，并发更新之间应该没有争用