公平性参数是调节线程调度倾向的旋钮：true偏向响应公平，false（默认）偏向吞吐量；公平锁通过AQS FIFO队列保障顺序执行，适合强序场景但代价是延迟略高；非公平锁允许CAS抢锁提升吞吐，适用于短临界区读操作但存在等待倾斜风险；需结合临界区耗时、线程数、外部调用等业务特征决策，并辅以锁释放保障、中断支持与监控优化。
直接看效果：公平性参数不是“开或关”的开关，而是调节线程调度倾向的旋钮——设为 true 时偏向响应公平，设为 false（默认）时偏向系统吞吐量。关键不在选哪个，而在懂它怎么影响排队、唤醒和CPU时间分配。
公平锁如何保障响应公平
公平锁强制线程按申请顺序排队，底层依赖AQS的FIFO等待队列。新线程请求锁时，不会跳过队列直接抢锁；哪怕锁刚释放，也会先唤醒队首线程，再由它获取。这种机制天然抑制“插队”，避免某个线程因持续被后来者抢占而长期饥饿。
- 适合场景：银行转账、订单扣减、审计日志写入等要求操作顺序严格、结果可预测的业务
- 代价明显：每次加锁都要检查队列状态、插入尾部、唤醒固定节点，上下文切换更频繁，单次操作延迟略高
- 注意：公平≠实时，只是顺序确定；若临界区执行时间长，整体响应仍可能变慢
非公平锁为什么提升吞吐量
非公平锁允许刚到的线程“先试一把”——用CAS直接抢锁，成功就跳过排队；失败才进队等待。这减少了锁释放后唤醒线程的等待时间，也降低了队列维护开销。尤其在短临界区（如计数器++、状态标记更新）中，大量线程能快速完成并释放锁，单位时间处理请求数显著上升。
- 典型适用：缓存读取、HTTP请求计数、状态快照生成等低延迟、高并发读操作
- 风险真实存在：极端负载下，队列尾部线程可能连续错过多次释放机会，出现可观测的等待倾斜
- 不是完全随机：JVM仍会定期唤醒等待队列中的线程，只是不保证“下一个就是你”
结合业务特征做参数决策
不能只看吞吐数字，要拆解临界区行为和系统瓶颈点。例如同一服务里，写操作用公平锁保序，读操作用非公平锁提效；或根据QPS动态切换——低峰期启用公平模式保障SLA，高峰期切回非公平应对突发流量。
立即学习“Java免费学习笔记（深入）”；
- 临界区耗时 < 1ms → 优先非公平，吞吐收益远大于公平开销
- 临界区涉及外部调用（DB、RPC）或耗时操作 → 公平锁更能防止某条慢请求拖垮整条队列
- 线程数稳定且较少（≤8）→ 公平锁性能折损小，公平性收益更突出
- 使用
tryLock(long, TimeUnit)配合超时，可缓解非公平锁下的无限等待风险
别忽略锁之外的协同优化
光调公平性参数不够。ReentrantLock本身是显式锁，必须配 try-finally 或 try-with-resources（配合自定义封装）确保释放；同时建议搭配 lockInterruptibly() 支持任务中断，避免因锁阻塞导致线程无法响应关闭信号。
- 避免在公平锁临界区内做I/O或长耗时计算，否则会把整个队列“堵死”
- 监控
getQueueLength()和hasQueuedThreads()，发现队列持续增长就要排查是否临界区过重或锁粒度太粗 - 若公平性与吞吐量都难兼顾，考虑降级方案：用无锁原子类（如
AtomicInteger）、分段锁（ConcurrentHashMap）、或读写分离（ReentrantReadWriteLock）
