Java并发--ReentrantReadWriteLock饥饿问题

最新推荐文章于 2025-01-21 22:10:05 发布

timo_xin

最新推荐文章于 2025-01-21 22:10:05 发布

阅读量2.2k

点赞数 1

分类专栏： Java 文章标签： java 多线程队列

本文链接：https://blog.youkuaiyun.com/weixin_41884010/article/details/107946192

版权

本文探讨了ReentrantReadWriteLock在读多写少情况下的饥饿问题，分析了公平性和非公平性竞争的区别。在非公平模式下，由于readerShouldBlock方法的逻辑，可能导致写锁获取困难，造成饥饿。而在公平模式下，通过hasQueuedPredecessors方法判断，确保等待最长时间的线程有机会获取锁，从而避免饥饿。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

通过阅读ReentrantReadWriteLock的源码我们会发现ReentrantReadWriteLock内部通过AbstractQueuedSynchronizer来实现同步语义，在ReentrantReadWriteLock中拥有读锁与写锁。读锁是一种共享锁，允许多个线程同时获取锁，写锁是一种独占锁，同一时刻只允许一个线程获取。如果在读多写少的情况下，利用ReentrantReadWriteLock很容易造成饥饿问题。

饥饿问题：ReentrantReadWriteLock实现了读写分离，想要获取读锁就必须确保当前没有其他任何读写锁了，但是一旦读操作比较多的时候，想要获取写锁就变得比较困难了，因为当前有可能会一直存在读锁。而无法获得写锁。

正文

当我们创建一个ReentrantReadWriteLock对象时，默认是非公平性。如果设置ReentrantReadWriteLock为公平性就不会存在饥饿问题，公平性获取锁会让等待最长时间的线程获取锁，只要获取写锁的线程等待的时间足够长，就一定会获取到锁。因此我们重点需要关注非公平性竞争。

下面的代码是饥饿问题的关键。

    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = -8159625535654395037L;
        final boolean writerShouldBlock() {
            return false; // writers can always barge
        }
        final boolean readerShouldBlock() {
            /* As a heuristic to avoid indefinite writer starvation,
             * block if the thread that momentarily appears to be head
             * of queue, if one exists, is a waiting writer.  This is
             * only a probabilistic effect since a new reader will not
             * block if there is a waiting writer behind other

最低0.47元/天解锁文章