SynchronousQueue的公平模式使用FIFO队列（TransferQueue），按到达顺序匹配；非公平模式使用LIFO栈（TransferStack），仅匹配栈顶，吞吐更高但可能饥饿。
SynchronousQueue 不是传统意义上的队列，它不存储元素，只负责“手递手”式地传递数据——一个线程生产，必须等待另一个线程消费；反之亦然。它的核心是“配对”（match）：生产者与消费者线程在同一个节点上直接交换数据。公平性（Fairness）决定的是这个配对过程的调度策略，而非锁的获取顺序。
公平模式：FIFO 配对队列 + 线程唤醒顺序保证
启用公平模式（构造时传 true）后，SynchronousQueue 内部使用一个 CLH 锁风格的双向等待队列（WaitQueue），所有未配对的线程（无论是 put 还是 take）都按进入顺序排队。
- 新来的线程（比如调用
put()）会创建一个QNode节点，尾插进等待队列，并自旋 + park 等待匹配； - 当另一个线程调用
take()时，它从队列头开始遍历，找到第一个类型相反的等待节点（即 head 是 put 节点，则 take 线程尝试匹配它）； - 匹配成功后，两个线程通过 CAS 修改节点状态、交换数据，并 unpark 对方；
- 关键点：匹配严格遵循队列顺序 —— 先到的 put 必须优先被先到的 take 匹配，不会跳过中间节点，从而实现 FIFO 公平性。
非公平模式：栈结构 + LIFO 尝试 + 自旋优化
默认（非公平）模式下，SynchronousQueue 使用一个 无锁栈（Treiber Stack） 来管理等待节点，核心思想是“后进先出”+“快速自旋探测”：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 每个线程入栈时 push 自己的
QNode（栈顶为最新等待者）； - 当一个线程（如 take）到来，它先尝试和栈顶节点“配对”（CAS 比较并交换状态）；
- 若失败（比如栈顶也是 take，或已被其他线程抢走），它再尝试 pop 栈顶继续向下匹配，但**不保证遍历全部**；
- 更激进的是：它还会在匹配前做几轮短时自旋（spin），检查是否有刚入栈、尚未 park 的“热”节点可立即配对，减少上下文切换；
- 结果是：最后入栈的线程最可能被优先匹配，存在“插队”现象，吞吐更高，但可能饿死早到的线程。
配对动作本身：CAS + volatile + Unsafe.park/unpark
无论公平与否，实际数据交换逻辑高度一致，依赖底层原子操作：
立即学习“Java免费学习笔记（深入）”；
- 每个
QNode有item（存放数据或 null）、isData（标识是数据还是请求）、waiter（指向阻塞线程）、next（链表/栈指针）等字段； - 匹配时双方线程通过
UNSAFE.compareAndSetObject原子更新对方节点的item和自身状态； - 一旦确认配对成功，立刻调用
LockSupport.unpark(matchedThread)唤醒对方；被唤醒线程检查自己的item是否已被填充，然后返回； - 整个过程无 synchronized，纯 lock-free，靠 CAS + volatile + park/unpark 协作完成零拷贝传递。
为什么没有“锁”却要分公平/非公平？
这里的“公平”不是指 synchronized 或 ReentrantLock 的公平锁语义，而是指等待线程获得匹配机会的调度顺序策略：
- 公平模式用队列强制顺序，适合对响应时间一致性要求高的场景（如实时任务协调）；
- 非公平模式用栈+自旋，牺牲顺序性换取更低延迟和更高吞吐，适合大多数通用高并发场景；
- 两者共享同一套配对原语（CAS 更新 item + unpark），差异仅在于“去哪里找对手”以及“按什么顺序找”。
