公平模式（fair=true）启用FIFO调度，避免线程饥饿但吞吐量降低15%–30%；非公平模式允许插队、提升吞吐，但可能引发延迟波动与个别线程长期等待。
公平性参数如何影响线程调度行为
设置 fair = true 会让 ArrayBlockingQueue 内部使用 ReentrantLock(true)，从而启用 FIFO 等待队列。这意味着当多个线程同时阻塞在 take() 或 put() 上时，锁释放后优先唤醒等待最久的线程，而非让新来的线程“插队”。但代价是每次入队/出队都需维护 CLH 队列节点、执行更严格的 CAS + volatile 写，吞吐量通常比非公平模式低 15%–30%。
高竞争下“线程饥饿”的真实诱因不是公平性开关本身
真正导致饥饿的往往是任务处理时间严重不均，或生产者/消费者速率长期失衡。比如一个慢消费者持续占着锁处理耗时操作，其他消费者即使排在队首也得等它完成——这时开公平模式只能保证“排队顺序”，不能解决“单个线程霸占资源太久”的问题。常见错误现象包括：
- 监控显示
Thread.getState()长期为WAITING，但队列长度始终不降 -
jstack中大量线程卡在AbstractQueuedSynchronizer$ConditionObject.await() - 开启
fair = true后延迟毛刺减少，但 P99 延迟仍居高不下
公平模式在什么场景下值得开启
仅当满足以下全部条件时，开启 fair = true 才有实际收益：
- 消费者线程数固定且远小于 CPU 核心数（如 4 个消费者跑在 32 核机器上）
- 每个任务执行时间波动小（标准差
- 业务对尾部延迟敏感（如实时风控、金融报价），能接受平均吞吐下降
- 已排除 GC 暂停、锁内阻塞 I/O、死循环等其他饥饿根源
否则，更应优先优化任务粒度、增加消费者数量，或改用无锁队列（如 MpscUnboundedArrayQueue）。
验证公平性是否生效的最小检查点
不要依赖日志或耗时对比，直接看线程等待行为：
- 用
jcmd观察VM.native_memory summary Internal内存是否随线程数线性增长（公平模式会为每个等待线程分配 AQS Node） - 在
take()前打点记录System.nanoTime()，采样 1000 次后排序，若非公平模式下前 10% 等待时间方差极大，而公平模式下呈近似线性分布，说明生效 - 注意：JDK 8u271+ 对非公平模式做了自适应优化，某些负载下两者的差异已大幅收窄
公平性不是银弹。它只约束“谁先拿到锁”，不约束“拿到锁后干多久”。高竞争系统里，锁持有时间永远比谁先抢到锁更关键。
