公平模式下synchronousqueue使用fifo队列严格按调用顺序匹配put/take线程，通过transferqueue实现，吞吐较低但顺序确定；非公平模式用lifo栈（transferstack）就近配对，吞吐高但可能饿死老线程。
公平模式下 SynchronousQueue 是怎么排队的
公平模式用的是 FIFO 队列，谁先 put 或 take，谁就优先匹配。比如线程 A 调用 put 后阻塞，线程 B 紧接着调用 take，那它们立刻配对；但如果线程 C 在 B 之前也调用了 take，C 就排在 B 前面——顺序严格按调用时间。
实际中容易误以为“公平 = 执行快”，其实它牺牲吞吐换确定性：多个线程竞争时，上下文切换更频繁，put/take 平均耗时会上升。
- 构造时显式指定：
new SynchronousQueue(true) - 不传参默认是非公平（
new SynchronousQueue()等价于new SynchronousQueue(false)） - JDK 9+ 中公平模式底层用
TransferQueue实现，非公平用TransferStack
非公平模式为什么默认用栈结构
非公平模式本质是 LIFO，后进先出。最新来的 put 线程会优先和最新来的 take 线程配对，跳过前面排队的线程。这带来两个关键效果：缓存局部性更好、线程唤醒更集中，所以吞吐更高。
但副作用明显：老线程可能饿死。比如一个慢消费者反复 take 失败，新生产者不断涌入，它就一直卡在队列头动不了。
- 栈结构让匹配逻辑变成“就近配对”，减少跨核缓存同步开销
- 在高并发短任务场景（如 ForkJoinPool 工作窃取），非公平性能通常高出 20%~40%
- 错误现象：
Thread.getState()长期显示WAITING，但堆栈里没别的线程在等——大概率是被新请求持续插队
TransferStack 和 TransferQueue 的实现差异在哪
这两个类不是 public API，但理解它们能解释行为差异。前者是无锁栈，靠 CAS 修改栈顶指针；后者是带哨兵节点的双向链表，插入/删除都要更新前后指针。
栈结构单次操作平均只需 1 次 CAS，队列往往要 2~3 次——这就是非公平模式更快的底层原因。不过栈对 GC 更友好：节点生命周期短，基本不进入老年代。
-
TransferStack节点有WAITING/FULFILLING两种状态，状态转换靠自旋 + CAS -
TransferQueue节点必须维护prev/next引用，对象体积更大，且链表遍历有 cache miss 风险 - 从 JDK 8 到 JDK 17，两者的 CAS 失败重试策略越来越激进，非公平优势进一步放大
什么时候该强制用公平模式
只有当你明确需要响应顺序可预测时才选公平模式，比如实时音视频帧调度、金融订单撮合这类对延迟抖动敏感的场景。
多数业务代码根本不需要——Spring 的 ThreadPoolTaskExecutor 默认用非公平 SynchronousQueue，Dubbo 的消费端线程池也是。盲目切公平，反而可能把 P99 延迟拉高一倍。
- 典型信号：监控发现
take平均等待时间波动极大（>5ms），且线程 dump 显示大量WAITING on java.util.concurrent.SynchronousQueue$TransferStack - 测试时别只看吞吐，用
jstack抓几次现场，确认阻塞线程是否真的按预期顺序唤醒 - 公平模式无法解决“生产者太快、消费者太慢”的根本问题，只是让慢线程饿得更规律
真正难的不是选公平还是非公平，而是判断你的场景到底有没有顺序敏感性。很多所谓“要公平”的需求，其实是没压测过非公平的真实表现。
