SynchronousQueue公平与非公平模式解析

SynchronousQueue 的公平与非公平模式本质是吞吐与顺序确定性之间的权衡：公平模式通过 FIFO 队列（TransferQueue）严格按调用时序匹配线程，保障响应可预测，适合音视频调度、金融撮合等对延迟抖动敏感的场景，但以更高上下文切换和 CAS 开销为代价，吞吐更低；非公平模式则采用 LIFO 栈（TransferStack），实现就近配对、缓存友好、单次操作更轻量，显著提升高并发短任务场景下的吞吐（常高出20%~40%），却可能导致老线程饿死——而 JDK 默认非公平并非随意设计，而是源于真实业务中绝大多数场景（如 Spring 线程池、Dubbo 消费端）更看重整体性能与资源效率；真正关键的决策点，不在于盲目追求“公平”，而在于通过压测、线程堆栈分析和延迟波动监控，冷静判断你的业务是否真的存在不可妥协的顺序敏感性。

公平模式下 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 抓几次现场，确认阻塞线程是否真的按预期顺序唤醒
• 公平模式无法解决“生产者太快、消费者太慢”的根本问题，只是让慢线程饿得更规律

真正难的不是选公平还是非公平，而是判断你的场景到底有没有顺序敏感性。很多所谓“要公平”的需求，其实是没压测过非公平的真实表现。

本篇关于《SynchronousQueue公平与非公平模式解析》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！