java - ReentrantReadWriteLock的 "non-fair"模式怎么理解？

Question

ReentrantReadWriteLock 有公平和非公平(默认)模式，但是文档太难理解了。

我怎么理解呢？如果有一些代码示例来演示它，那就太好了。

更新

如果我有一个写线程和很多读线程，哪种模式更好用？如果我使用非公平模式，写线程是否有可能获得锁的机会很小？

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 次正面朝上的可能性相同。

我相信在非公平锁定的实现中使用了一种有点“公平”的硬币。所以问题真的变成了公平性(因此，延迟)与吞吐量。使用非公平锁定通常会带来更好的吞吐量，但代价是锁定请求的延迟偶尔会出现峰值。哪个更适合您取决于您​​自己的要求。