如何理解ReentrantReadWriteLock的“不公平”模式？

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个连续正面的可能性差不多。

我相信在非公平锁定的实现中，会使用某种“公平”的硬币。因此，问题实际上变成了公平性（以及 延迟
）与吞吐量之间的关系。使用非公平锁定通常可以提高吞吐量，但要以偶尔出现的锁定请求延迟时间为代价。哪种更适合您取决于您​​自己的要求。