SynchronousQueue的“零容量”指其根本不存储元素，put必须等待take配对完成“手递手”交付，数据直接在线程间传递，不经过任何缓冲区。
SynchronousQueue 的“零容量”不是指队列里存了 0 个元素，而是它根本不存储元素——它不保留任何待消费的数据，所有 put 操作必须等待一个配套的 take（或 poll）操作同时发生，反之亦然。这种“交付即完成”的机制，就是它实现无中转、零容量交付的核心。
交付发生在生产者与消费者线程的直接握手之间
不同于 ArrayBlockingQueue 或 LinkedBlockingQueue 会把元素暂存在内部数组或链表中，SynchronousQueue 没有数据缓冲区。当线程 A 调用 put(x) 时：
- 如果此时有另一个线程 B 正在调用
take()并处于等待状态，A 和 B 会直接交换引用：x 从 A 的栈帧“跨线程”交给 B 的栈帧，中间不经过任何堆内存中的队列节点； - 如果此时没有等待的消费者，A 会被阻塞，直到有线程来 take；
- 同理，
take()也必须等到有线程正在put，否则挂起。
这个过程由底层的 Transferer（JDK 7+ 使用 TransferStack 或 TransferQueue）协调，本质是线程间的一次原子性“配对移交”，数据不落盘、不入队、不复制。
两种实现模式：公平 vs 非公平，影响配对策略
SynchronousQueue 内部有两种传输器实现，通过构造参数 fair 控制：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
fair = true：使用
TransferQueue（FIFO 队列），先到的生产者/消费者优先匹配，保证严格的等待顺序； -
fair = false（默认）：使用
TransferStack（LIFO 栈），后到的线程优先尝试“抢占式”配对，吞吐更高但可能造成饥饿。
无论哪种，都不改变“无存储”本质——栈或队列里存放的只是等待线程的 WaitNode（包装了线程和等待条件），不是数据本身。
典型适用场景：手递手任务交接
正因为它不缓存，SynchronousQueue 天然适合需要强耦合协作的场景：
- 工作窃取线程池（如 ForkJoinPool）中，空闲线程直接向繁忙线程“索要”任务；
- 生产者-消费者严格一对一绑定，比如一个 HTTP 请求线程生成任务，立刻交由专用 IO 线程处理，不允许积压；
- 作为 Executors.newCachedThreadPool() 的默认阻塞队列，让新任务必须“撞上”刚创建或空闲的线程才能执行，避免任务排队延迟。
一旦出现生产速率 > 消费能力，未匹配的 put 会持续阻塞，这本身就是背压（backpressure）信号——系统告诉你：“慢点来，没人接。”
注意：poll(timeout) 和 offer() 不阻塞，但仍是零容量逻辑
即使使用带超时的 poll(1, TimeUnit.SECONDS) 或非阻塞的 offer(x)：
-
offer(x)只有在**此刻恰好有线程在 take** 才返回 true，否则立即返回 false； -
poll(timeout)会在超时时间内等待配对，若超时则返回 null； - 它们不改变“无缓冲”语义，只是把阻塞行为改为限时或不阻塞而已。
换句话说：它永远不“收下再转交”，只做“当场交接”。没对手？那就不交。
