公平模式只确保线程按请求顺序获取许可（fifo），不保证执行时间相等或缩短单次延迟；它通过hasqueuedpredecessors()强制后到线程入队尾，避免插队饥饿，使最大等待时间可估算，适用于金融等强顺序场景。
启用公平模式是提升系统响应可预测性的有效手段，但不是单纯“开启”就能见效。关键在于理解它如何改变线程调度行为，并配合许可数、临界区耗时等要素协同优化。
公平模式真正保障的是什么
公平模式不保证每个线程执行时间相等，也不缩短单次响应延迟，它只确保线程按请求顺序获取许可——即先到先得（FIFO）。源码中通过 hasQueuedPredecessors() 检查队列头部是否有等待者，若有则拒绝当前线程直接抢占，强制其入队尾部。
- 避免了后提交的线程反复“插队”成功，导致前面线程长期饥饿
- 使最大等待时间可估算：若平均任务耗时为 T，许可数为 N，队列长度为 Q，则最坏等待时间约为 (Q / N) × T
- 在金融、订单、审批等强顺序敏感场景中，这是稳定性底线
为什么公平模式有时反而拉高平均延迟
看似有序的排队，会放大两类开销：
- 上下文切换更频繁：线程释放许可后，唤醒的是队列头部线程；而该线程可能刚被调度出去不久，CPU缓存热度低，恢复成本高
- 许可空闲期被拉长：非公平模式下，新线程可能在释放瞬间“抢到”许可；公平模式下必须等前序线程完成唤醒、调度、执行上下文加载全过程，中间存在微小但累积的间隙
- 当临界区操作本身耗时波动大（如含I/O或远程调用），公平队列会把长任务“卡”在队首，后续所有线程被动等待
让公平竞争真正提升响应性的实操要点
单靠设置 new Semaphore(permits, true) 不足以达成目标。需同步调整以下三点：
- 许可数要匹配资源吞吐瓶颈：例如数据库连接池最大连接数为20，信号量许可也应设为20，而非拍脑袋定10；否则队列积压是常态，公平只是“排长队”的公平
- 临界区务必轻量化：禁止在 acquire() 和 release() 之间做日志刷盘、HTTP调用、复杂计算；这些应移出临界区，仅保留核心资源访问逻辑
- 搭配 tryAcquire(timeout) 做兜底：对延迟敏感的操作，改用带超时的获取方式，避免某一线程卡死拖垮整条队列；超时后可降级、重试或返回失败，不阻塞他人
公平与非公平不是二选一，而是分层使用
大型系统中，不同层级资源适合不同策略：
- 底层数据库连接：用公平信号量，防止慢查询线程饿死快查询请求
- 中间层API限流：用非公平信号量，追求高吞吐，辅以滑动窗口平滑突发流量
- 前端任务队列：可混合——入队用公平保障用户请求顺序，执行用非公平提升吞吐
