ReentrantLock 的公平与非公平：你真的懂吗？一线工程师的实战经验分享

很多 Java 开发者都听说过 ReentrantLock，也知道它可以用来实现互斥锁，保证线程安全。但是，ReentrantLock 的公平与非公平机制，却常常让人感到困惑。这篇文章，我将结合自身多年的开发经验，深入浅出地讲解 ReentrantLock 的公平与非公平机制，并分享一些实际应用中的案例和经验，希望能帮助你更好地理解和运用这个强大的工具。

公平锁与非公平锁：到底有什么区别？

ReentrantLock 提供了两种模式：公平锁和非公平锁。它们的区别在于线程获取锁的顺序：

• 公平锁: 线程获取锁的顺序严格按照它们请求锁的顺序来。先来先得，后来的线程必须排队等待。
• 非公平锁: 线程获取锁的顺序不保证是按照请求顺序来。后来的线程可能插队，在等待队列的线程之前获取锁。

默认情况下，ReentrantLock 是非公平锁。那么，为什么会有公平锁和非公平锁这两种模式呢？它们各自的优缺点又是什么？

非公平锁的优势：更高的吞吐量

非公平锁之所以成为默认模式，是因为它通常具有更高的吞吐量。这是因为非公平锁避免了线程在等待队列中频繁的上下文切换，减少了系统开销。当一个线程释放锁时，如果此时有其他线程正在尝试获取锁，非公平锁会直接让这个线程获取锁，而不用考虑队列中的其他线程。这种机制减少了等待时间，提高了效率。

想象一下，像一个高速公路收费站，非公平锁就像允许车辆直接插入空位收费，而不用排队等候；公平锁则像严格按照车道顺序收费。后者虽然公平，但会降低整体的通行效率。

公平锁的优势：保证公平性

公平锁的优势在于它能够保证公平性。所有等待的线程都将按照FIFO（先进先出）的原则获取锁。这对于一些对公平性要求较高的场景非常重要，例如，你需要确保所有线程都有机会获得资源。

但是，公平性是以牺牲吞吐量为代价的。由于公平锁需要维护一个等待队列，并且需要在每次释放锁时进行队列的调度，因此效率会比非公平锁低。

选择哪种模式？

那么，在实际应用中，我们应该选择哪种模式呢？这取决于具体的应用场景：

• 如果吞吐量是首要考虑因素，那么非公平锁是更好的选择。 绝大多数情况下，非公平锁的性能更好。
• 如果公平性是必须的，那么公平锁是唯一的选择。 例如，在一些资源竞争非常激烈的场景，公平锁可以防止某些线程长时间霸占资源，保证所有线程都有机会访问资源。

实际应用案例

我曾经在一个高并发的数据处理系统中使用过 ReentrantLock。起初，我使用了默认的非公平锁，系统性能非常好。但是，后来发现，某些线程经常获取不到锁，导致数据处理延迟严重。经过分析，我们发现，这些线程总是被其他线程抢先获取锁，导致它们长时间处于等待状态。

为了解决这个问题，我们尝试将 ReentrantLock 切换为公平锁。结果，虽然系统的吞吐量有所下降，但公平性得到了保证，所有线程都能获得公平的资源访问机会，数据处理的延迟也降低了。

这个案例说明，选择公平锁还是非公平锁，需要根据实际情况进行权衡。没有绝对的优劣之分，只看哪一个更适合你的应用场景。

总结

ReentrantLock 的公平与非公平机制是并发编程中一个重要的概念。理解它们的区别和优缺点，对于编写高效和可靠的多线程程序至关重要。希望这篇文章能够帮助你更好地掌握 ReentrantLock，并在实际应用中做出更明智的选择。记住，选择哪种模式，需要根据实际场景进行权衡，没有绝对的答案。