公平锁与非公平锁性能分析

### 一、默认使用非公平锁 ReentrantLock 默认情况下确实使用**非公平锁**。 • 当通过无参构造函数 `new ReentrantLock()` 创建锁时，底层会初始化 `NonfairSync`（非公平锁实现类）。 • 公平锁需要通过显式参数设置，例如 `new ReentrantLock(true)`。 ### 二、非公平锁的效率和吞吐量优势 非公平锁的性能和吞吐量显著优于公平锁，主要原因如下： #### 1. **减少线程切换开销** • 非公平锁允许新请求的线程直接尝试抢占锁，无需严格遵循队列顺序。例如，当一个线程释放锁时，新线程可能立即抢占成功，而无需唤醒队列中的等待线程，减少了上下文切换次数。 • 公平锁每次必须按队列顺序唤醒线程，频繁的线程切换会降低吞吐量。 #### 2. **CAS 操作的优化** • 非公平锁在首次尝试获取锁时直接使用 CAS（Compare-And-Swap）操作抢占锁，若成功则省去排队过程。而公平锁需先检查队列是否有等待线程，再决定是否尝试 CAS。 #### 3. **适用高并发短任务场景** • 在锁持有时间较短的场景（如计数器、缓存操作），非公平锁的插队机制能更快响应请求，减少等待时间。 #### 4. **数据支持** • 根据实际测试，非公平锁的吞吐量通常比公平锁高 **5~10 倍**，尤其在竞争激烈时差异更明显。 ### 三、公平锁的适用场景 尽管非公平锁性能更优，公平锁在以下场景不可替代： 1. **严格顺序性要求** 如支付系统需按请求顺序处理交易。 2. **避免线程饥饿** 公平锁保证每个线程最终都能获取锁，适合长任务或优先级敏感的场景。 ### 四、总结 • **默认选择非公平锁**：ReentrantLock 默认使用非公平锁，性能优势显著。 • **权衡公平性与性能**：非公平锁适合高并发、短任务；公平锁适合对顺序敏感的场景。 • **实际建议**：优先使用非公平锁，仅在明确需要公平性时切换为公平锁。