此问题在此处已有答案:
Will Readlock and Writelock cause starvation for writer?(1个答案)
3天前关闭。
在为工作编写代码时,我遇到了ReentrantReadWriteLock的用例。到目前为止,我的理解是,只要具有读锁的线程超过零,线程就无法获得写锁。我正在处理的应用程序是读重型的,写操作很少。是否有可能总是有多于零个线程获得读锁,而如果一个线程需要写锁,它将永远被挂起?
此问题在此处已有答案:
Will Readlock and Writelock cause starvation for writer?(1个答案)
3天前关闭。
在为工作编写代码时,我遇到了ReentrantReadWriteLock的用例。到目前为止,我的理解是,只要具有读锁的线程超过零,线程就无法获得写锁。我正在处理的应用程序是读重型的,写操作很少。是否有可能总是有多于零个线程获得读锁,而如果一个线程需要写锁,它将永远被挂起?
1条答案
按热度按时间t9aqgxwy1#
这被称为“作家饥饿”。
查看ReentrantReadWriteLock的Javadoc时,我们可以找到以下段落:
此类不对锁访问施加读取器或写入器首选项排序。但是,它支持可选的公平策略。
非公平模式(默认值)当构造为非公平(默认值)时,进入读锁和写锁的顺序是不指定的,受可重入性约束。持续争用的非公平锁可能会无限期地推迟一个或多个读线程或写线程,但通常比公平锁具有更高的吞吐量。
公平模式当被构造为公平时,线程使用近似到达顺序策略竞争入口。当当前持有的锁被释放时,等待时间最长的单个写线程将被分配写锁,或者如果有一组读线程等待的时间比所有等待的写线程都长,该组将被分配读锁。
尝试获取公平读取锁定的线程(不可重入)将阻塞,如果写锁被持有,或者有一个等待的写线程。线程将不会获得读锁,直到最早的当前等待的写线程已经获得并释放写锁。当然,如果等待的写线程放弃其等待,留下一个或多个读取器线程作为队列中最长的等待者,而写锁定是空闲的,则那些读取器将被分配读锁定。
尝试获取公平写锁(非重入)的线程将阻塞,除非读锁和写锁都空闲(这意味着没有等待线程)。(注意,非阻塞的ReentrantReadWriteLock.ReadLock.tryLock()和ReentrantReadWriteLock.WriteLock.tryLock()方法不荣誉这种公平设置,如果可能,将立即获取锁,而不管等待线程是什么。)
简而言之:如果您不指定ReentrantReadWriteLock使用公平策略,则可能发生这种情况