ReentrantLock 的公平与非公平：深度剖析其实现机制与性能差异

2024/11/29 10:09:16 77 0 0 0

ReentrantLock 的公平与非公平：深度剖析其实现机制与性能差异

ReentrantLock 是 Java 并发编程中一个非常重要的工具，它提供了一种比 synchronized 更灵活的锁机制。ReentrantLock 的一个关键特性就是它可以配置为公平锁或非公平锁。那么，什么是公平锁和非公平锁？它们之间有什么区别？又该如何选择呢？本文将深入探讨 ReentrantLock 的公平与非公平机制，并分析其在实际应用中的性能差异。

1. 公平锁与非公平锁的概念

公平锁: 公平锁保证线程获取锁的顺序与它们请求锁的顺序一致。先请求锁的线程先获得锁。这就像排队买票，先来后到。
非公平锁: 非公平锁没有严格的顺序要求。线程获取锁的顺序是随机的，即使其他线程先请求锁，它也可能抢先获得锁。这就像自由搏击，谁先抢到谁就赢了。

ReentrantLock 默认是非公平锁。这是因为公平锁的实现机制会引入额外的开销，降低性能。

2. ReentrantLock 的实现机制

ReentrantLock 的实现基于 AQS（AbstractQueuedSynchronizer），AQS 是一个用于构建锁和同步器的框架。在 AQS 中，线程通过一个双向链表来排队等待锁。

公平锁的实现: 公平锁的 AQS 实现会严格按照 FIFO（先进先出）的顺序从队列中获取节点，保证先请求锁的线程先获得锁。
非公平锁的实现: 非公平锁的 AQS 实现则会尝试直接抢占锁，如果成功则直接获取锁；如果失败，则进入队列等待。这种机制提高了性能，但牺牲了公平性。

具体来说，非公平锁在尝试获取锁时，会先尝试无条件地 CAS（Compare And Swap）操作来获取锁。如果 CAS 成功，则表示该线程成功获取锁；如果失败，则说明其他线程已经持有锁，该线程将进入 AQS 队列等待。

而公平锁则需要在获取锁前检查队列中是否有等待的线程，如果有则需要排队等待，只有当队列为空或当前线程是队列中的第一个线程时，才能尝试获取锁。

3. 性能差异分析

公平锁虽然保证了公平性，但会引入额外的开销，降低性能。这是因为公平锁需要维护一个严格的队列，每次获取锁都需要检查队列，这会增加 CPU 的竞争和上下文切换的次数。

非公平锁则性能更高，因为它避免了队列的维护和检查，直接尝试获取锁。但是，非公平锁可能会导致某些线程长时间等待，造成“饥饿”现象。

在实际应用中，非公平锁通常是更好的选择，除非公平性至关重要。如果你对公平性有极高的要求，比如需要保证所有线程都能得到公平的资源分配，那么可以选择公平锁。但是，在大多数情况下，非公平锁的性能优势更为明显。

4. 实践案例与代码示例

以下是一个简单的示例，演示了如何使用 ReentrantLock 创建公平锁和非公平锁：

import java.util.concurrent.locks.ReentrantLock;

public class FairAndUnfairLock {
    private final ReentrantLock fairLock = new ReentrantLock(true); // 公平锁
    private final ReentrantLock unfairLock = new ReentrantLock(false); // 非公平锁

    // ... (代码略) ...
}

在实际应用中，需要根据具体的场景选择合适的锁类型。如果需要保证公平性，可以选择公平锁；如果性能更重要，可以选择非公平锁。

5. 总结

ReentrantLock 的公平与非公平机制是其灵活性的关键所在。理解其实现机制和性能差异，才能在实际应用中做出正确的选择。在大多数情况下，非公平锁是更好的选择，因为它具有更高的性能。但是，如果公平性至关重要，则可以选择公平锁。记住，选择哪种锁取决于你的具体需求，权衡性能和公平性。选择最适合你应用场景的锁机制，才能最大限度地提高效率和稳定性。

老码农 Java 并发编程 ReentrantLock 锁多线程

ReentrantLock 的公平与非公平：深度剖析其实现机制与性能差异