在为工作编写一段代码时，我遇到了ReentrantReadWriteLock的用例。到目前为止，我的理解是，只要有超过零的线程读锁一个线程不能获得写锁。我正在开发的应用程序读取量很大，写入量很少。是否有可能超过零的线程总是获得读锁，如果一个线程需要写锁，它将永远被挂起?
这就是所谓的"作家饥饿"。
当查看Javadoc的ReentrantReadWriteLock时，我们可以找到以下段落:
这个类不强制reader或writer的优先顺序锁的访问。但是，它确实支持一个可选的公平策略。
非公平模式(默认)当构造为非公平(默认)时，读和写锁的进入顺序是未指定的，主题重入约束。连续的非公平锁争用可能无限期地延迟一个或多个读取器或写入器线程，但通常会有比公平锁更高的吞吐量。
公平模式当被构造为公平模式时，线程使用近似到货政策。当前持有的锁为发布后，等待时间最长的单作者线程将是分配了写锁，或者如果有一组读线程该组等待的时间比所有等待的写线程都长已分配读锁
尝试获取公平读锁(不可重入)的线程将会如果写锁被持有，或者有一个等待的写器，则阻塞线程。对象之后，线程才会获得读锁当前等待时间最长的写入线程已获取并释放写锁。当然，如果一个等待的作家放弃了等待，离开了一个或多个读取线程作为队列中最长的等待者当写锁释放后，这些读取器将被分配读锁锁。
试图获得公平写锁的线程(不可重入)将阻塞，除非读锁和写锁都空闲(哪个意味着没有等待线程)。(注意非阻塞ReentrantReadWriteLock.ReadLock.tryLock()和ReentrantReadWriteLock.WriteLock.tryLock()方法不支持这个公平设置，如果可能，将立即获得锁。不考虑等待线程)
简而言之:如果您没有指定ReentrantReadWriteLock使用公平的策略，则可能发生这种情况