synchronousqueue 不是队列而是“手递手”通道，因它不存储元素，offer()和poll()总失败，仅put()与take()成对阻塞同步；size()恒为0，适用于严格配对的线程间一次性数据传递。
为什么 SynchronousQueue 不是“队列”，而是“手递手”通道
它根本存不住元素——offer() 和 poll() 总是立即失败，只有 put() 和 take() 能成功，且必须成对阻塞等待。这不是缓冲区，是两个线程的同步点：一个线程调用 put() 后立刻挂起，直到另一个线程恰好调用 take()，此时数据才“越过边界”，双方同时解除阻塞。
常见错误是把它当 ArrayBlockingQueue 用，比如先 offer() 再去 poll()，结果永远拿不到值，因为 SynchronousQueue 不接受“暂存”。
最简握手模式：生产者-消费者必须严格配对
典型场景是任务委托、响应式回调、或线程间一次性参数传递（如主线程把初始化配置交给工作线程，等它启动完成再继续）。
-
put()和take()必须在不同线程中调用；同一线程里顺序调用会死锁 - 超时控制很关键：
offer(E, long, TimeUnit)和poll(long, TimeUnit)是非阻塞变体，但依然要求对方“正在等”或“即将来等”，否则返回false或null - 不要依赖容量判断：
size()永远返回0，isEmpty()永远返回true—— 这是设计使然，不是 bug
实际例子：主线程等子线程完成初始化
比如启动一个网络连接器，需要确保它真正连上后再让后续逻辑执行：
SynchronousQueue<boolean> readySignal = new SynchronousQueue();
Thread worker = new Thread(() -> {
try {
// 模拟耗时初始化
connectToServer();
// 成功后发出信号
readySignal.put(true); // 阻塞直到主线程 take()
} catch (Exception e) {
try {
readySignal.put(false);
} catch (InterruptedException ignored) {}
}
});
worker.start();
// 主线程阻塞等待结果
Boolean success = readySignal.take(); // 这里卡住，直到 worker put
if (!success) throw new RuntimeException("Init failed");
</boolean>
注意：如果 worker 因异常提前退出且没调用 put()，主线程会永久阻塞——这是最容易被忽略的风险点，必须配合超时或中断处理。
和 LinkedTransferQueue 的关键区别在哪
有人会想：“既然都要配对，那用 LinkedTransferQueue.transfer() 不也一样？” 不一样：
-
SynchronousQueue是纯同步交付，无任何内部节点，内存开销趋近于零；LinkedTransferQueue有链表结构，能缓存未匹配的请求（即transfer()在无人take()时会暂存节点） -
SynchronousQueue的吞吐在高配对率下更高，但一旦配对失衡（比如生产者快、消费者慢），就会大量线程阻塞；LinkedTransferQueue更“宽容”，但也带来 GC 和内存占用成本 - 调试时看线程堆栈：
SynchronousQueue的阻塞线程一定停在put()或take()的LockSupport.park()，而LinkedTransferQueue可能停在awaitMatch()或节点自旋上
真正需要“零延迟、零缓冲、强配对语义”的场景，才该选 SynchronousQueue；只要有一点异步容忍度，就该考虑更稳的替代品。
