Java公平性案例

深度解析Java公平性案例：从锁机制到业务场景的实践指南

目录导读

1. Java公平性核心概念 – 理解公平与非公平的本质区别
2. ReentrantLock公平性源码分析 – 从CLH队列到线程调度
3. 业务场景中的公平性陷阱 – 避免性能与公平的失衡
4. 性能实测数据对比 – 吞吐量 vs 等待时间的真实权衡
5. 常见问题FAQ – 解答开发者的高频困惑

Java公平性核心概念：为什么需要“排队”？

在Java并发编程中,公平性（Fairness） 通常指线程获取锁的顺序是否遵循申请时间的先后，以ReentrantLock为例，它提供两种模式：公平锁（FIFO顺序）与非公平锁（允许抢占）。
关键区别：公平锁会检查等待队列中是否有更早的线程；非公平锁则先尝试CAS获取锁，失败后再入队。

问答环节
Q：公平锁一定比非公平锁慢吗？
A：不一定，在高竞争场景下，非公平锁可能因频繁上下文切换导致“饥饿”，而公平锁的排队机制能减少线程反复唤醒的开销，实际吞吐量可能更优（详见后文性能数据）。

ReentrantLock公平性源码分析：CLH队列的公正密码

ReentrantLock的公平性由内部类FairSync和NonfairSync实现，核心逻辑在acquire()方法中：

// 公平锁版本
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 关键点：公平锁先检查队列中是否有前驱节点
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    // ... 重入逻辑
    return false;
}
// 非公平锁版本
final boolean nonfairTryAcquire(int acquires) {
    // 直接尝试CAS，不检查队列
    if (c == 0 && compareAndSetState(0, acquires)) { ... }
}

实践洞察：hasQueuedPredecessors()方法通过遍历CLH双向队列，判断当前线程是否位于队列头部或队列为空，这个检查是公平性的“守护者”。

问答环节
Q：我能否在业务代码中强制使用公平锁来保证线程顺序？
A：可以，但需注意性能开销，例如在数据库连接池的wait-queue场景中，公平锁可防止短任务被长任务阻塞。

业务场景中的公平性陷阱：小心“伪公平”与“饥饿”

任务队列的公平调度

假设一个订单处理系统,使用ReentrantLock保护共享资源，若采用非公平锁，优先级高的订单（如VIP）可能始终插队，导致普通订单饥饿。
解决方案：使用公平锁并配合Condition的await()和signal()实现顺序唤醒。

线程池与公平性冲突

ThreadPoolExecutor的WorkQueue本身不保证公平，若结合公平锁可能造成调度混乱，此时应考虑使用PriorityBlockingQueue按优先级入队，但公平锁仅保证锁获取顺序。

问答环节
Q：我需要为每个线程分配唯一的锁获取顺序吗？
A：不需要，公平锁通过全局队列保证相对顺序，但若业务需要精确顺序（如日志同步），可使用StampedLock的乐观读模式。

性能实测数据对比：公平与非公平的博弈

以下为JMH基准测试（8核CPU，1000个并发线程，循环1万次）的典型结果：

分析：公平锁因减少线程唤醒次数，等待时间更稳定；非公平锁在低竞争下吞吐量高，但长尾延迟严重。
行动建议：IO密集型场景（如网络请求）使用公平锁，CPU密集型（如计算任务）使用非公平锁。

问答环节
Q：如果使用Synchronized，是否涉及公平性？
A：Synchronized是非公平的，且无法切换模式，在JDK 1.6后引入偏向锁和轻量级锁，但整体仍偏向非公平。

常见问题FAQ：开发者最关心的公平性疑问

Q1：如何动态切换公平与非公平模式？
A：ReentrantLock构造器指定后不可更改，建议通过工厂模式封装：Lock createLock(boolean fair)。

Q2：公平锁能否保证线程执行顺序？
A：仅保证锁的获取顺序，不保证线程内部逻辑执行顺序，若需全局顺序，建议使用ThreadPoolExecutor的submit()与Future。

Q3：在分布式系统中如何实现公平性？
A：可用ZooKeeper的临时有序节点或ETCD的租约实现全局队列，例如ZkDistributedLock的公平模式。

Q4：AQS的hasQueuedPredecessors()效率如何？
A：O(1)复杂度，因为仅检查头节点的后继，但频繁调用会增加CAS冲突，微基准测试显示损耗约5%性能。

Java公平性的最佳实践

选择公平锁的黄金法则：

• 当任务执行时间差异大（如混合长/短请求）→ 用公平锁防饥饿
• 当高并发低竞争（如缓存读操作）→ 用非公平锁提吞吐
• 当系统需要可预测延迟（如金融交易）→ 用公平锁配合StampedLock

最后给读者的建议：不要盲目追求公平性，先通过压测（如JProfiler或VisualVM）观察线程阻塞状态，再针对性调整，公平锁是工具而非银弹。