如何理解ReentrantReadWriteLock的"非公平"模式？

Question

ReentrantReadWriteLock具有公平和非公平(默认)模式,但该文档对我来说很难理解.

我怎么能理解呢？如果有一些代码示例来演示它,那就太棒了.

UPDATE

如果我有一个写线程,并且有很多阅读线程,哪种模式更好用？如果我使用非公平模式,写入线程是否有可能获得锁定？

Answer 1

非公平意味着当锁准备好通过新线程获得时,锁不能保证获得锁的人的公平性(假设当时有多个线程请求锁).换句话说,可以想象一个线程可能会持续缺乏,因为其他线程总是设法任意获取锁而不是它.

公平模式更像是先来先服务,其中线程保证一定程度的公平性,以便他们以公平的方式获得锁定(例如,在开始等待很长时间的线程之前).

编辑

这是一个示例程序,它演示了锁的公平性(因为公平锁的写锁请求是先到先得的).比较FAIR = true(线程总是按顺序提供)与FAIR = false(线程有时不按顺序提供)的结果.

import java.util.concurrent.locks.ReentrantReadWriteLock;

public class FairLocking {

    public static final boolean FAIR = true;
    private static final int NUM_THREADS = 3;

    private static volatile int expectedIndex = 0;

    public static void main(String[] args) throws InterruptedException {
        ReentrantReadWriteLock.WriteLock lock = new ReentrantReadWriteLock(FAIR).writeLock();

        // we grab the lock to start to make sure the threads don't start until we're ready
        lock.lock();

        for (int i = 0; i < NUM_THREADS; i++) {
            new Thread(new ExampleRunnable(i, lock)).start();

            // a cheap way to make sure that runnable 0 requests the first lock
            // before runnable 1
            Thread.sleep(10);
        }

        // let the threads go
        lock.unlock();
    }

    private static class ExampleRunnable implements Runnable {
        private final int index;
        private final ReentrantReadWriteLock.WriteLock writeLock;

        public ExampleRunnable(int index, ReentrantReadWriteLock.WriteLock writeLock) {
            this.index = index;
            this.writeLock = writeLock;
        }

        public void run() {
            while(true) {
                writeLock.lock();
                try {
                    // this sleep is a cheap way to make sure the previous thread loops
                    // around before another thread grabs the lock, does its work,
                    // loops around and requests the lock again ahead of it.
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    //ignored
                }
                if (index != expectedIndex) {
                    System.out.printf("Unexpected thread obtained lock! " +
                            "Expected: %d Actual: %d%n", expectedIndex, index);
                    System.exit(0);
                }

                expectedIndex = (expectedIndex+1) % NUM_THREADS;
                writeLock.unlock();
            }
        }
    }
}

编辑(再次)

关于你的更新,使用非公平锁定并不是说线程有可能获得锁定的可能性很小,而是线程必须等待一段时间的可能性很小.

现在,通常随着饥饿期的增加,实际发生的那段时间的概率降低......就像连续10次翻转硬币"头"一样,连续9次翻转硬币"头"的可能性较小.

但是,如果多个等待线程的选择算法是非随机化的,例如"具有按字母顺序排列的名称的线程始终获得锁定",那么您可能会遇到一个真正的问题,因为随着线程越来越多,概率不一定会降低更加饥饿...如果硬币被加权到"头部"10个连续的头部基本上与9个连续的头部一样可能.

我相信在非公平锁定的实现中使用了一些有些"公平"的硬币.所以问题确实变得公平(因此,延迟)与吞吐量.使用非公平锁定通常会产生更好的吞吐量,但代价是锁定请求偶尔会出现延迟峰值.哪个更适合您取决于您​​自己的要求.