'fair' 和 'unfair' 锁内部存储的区别

Question

带有类 Reentrant(true) lock 的 Lock 接口的工作方式是它使用BlockingQueue来存储想要获取锁的线程。以这种方式“先来，先出去”的线程-FIFO。都清楚这一点。

但是“不公平锁”到哪里去了，或者 ReentrantLock(false)。他们的内部实现是什么？操作系统如何决定现在选择哪个线程？最重要的是现在这些线程还存储在队列中还是在哪里？（他们一定在某个地方）

Answer 1

该类ReentrantLock不使用BlockingQueue. 它AbstractQueuedSynchronizer在幕后使用了一个非公开的子类。

在AbstractQueuedSynchronizer类，因为它的文档状态，维持“先入先出（FIFO）等待队列”。这个数据结构对于公平锁和不公平锁是一样的。不公平并不意味着锁会改变排队等待线程的顺序，因为这样做没有任何好处。

关键的区别在于，不公平的锁允许lock在锁刚被释放时立即尝试成功，即使有其他线程等待锁的时间更长。在这种情况下，队列甚至不涉及超车线程。这比将当前线程添加到队列并将其置于等待状态同时从队列中删除最长等待线程并将其状态更改为“可运行”更有效。

当锁不可用时，一个线程试图获取它，该线程将被添加到队列中，此时，公平锁和不公平锁对其没有区别（除了其他线程可能会在没有排队）。由于没有为不公平锁指定顺序，它可以在幕后使用 LIFO 数据结构，但对于两者只有一个实现代码显然更简单。

对于synchronized，而另一方面，它不支持公平收购，也有采用后进先出结构的一些JVM实现。这可能会从一个版本更改为另一个版本（甚至相同，作为某些 JVM 选项或环境方面的副作用）。

这方面的另一个有趣的一点是，该参数的tryLock()的的ReentrantLock实施将是不公平的，即使在锁否则公平模式。这表明不公平不是这里等待队列的属性，而是对进行新锁尝试的到达线程的处理。

即使此锁已设置为使用公平排序策略，如果可用，则调用tryLock() 将立即获取该锁，无论其他线程当前是否正在等待该锁。这种“闯入”行为在某些情况下很有用，即使它破坏了公平。