SynchronousQueue是零容量同步通道，不存储元素，put与take必须配对阻塞完成“手递手”交付，无缓冲、无复制、无中间状态，仅在生产者与消费者线程间直接传递引用。
SynchronousQueue 不是传统意义上的队列，它没有容量，不存储元素。一个线程想放数据，必须同时有另一个线程在等取；反之亦然。它本质是两个线程之间“手递手”完成数据交付的同步通道。
为什么说它是“零容量”的？
它的内部不保留任何待处理的元素。调用 put() 会阻塞，直到另一个线程调用 take()；同样，take() 也会阻塞，直到有线程调用 put()。没有缓冲、没有排队、没有中间状态——只有配对成功那一刻的数据交接。
- 构造时传入
true（公平模式）：按等待顺序匹配线程，先到先服务 - 默认非公平模式：匹配更灵活，但不保证 FIFO
- 不能调用
peek()、size()或isEmpty()获取有意义的结果，因为始终为空
典型使用场景：生产者-消费者严格一对一
适合需要强同步、低延迟、且天然成对的任务协作，比如：
- 工作窃取线程池中，空闲线程向忙碌线程“借任务”时的临时交接
- 异步回调中，将结果从后台线程直接交到等待的主线程手中（避免额外队列和唤醒开销）
- 实现“信号量式”的线程协调：一个线程发信号（
put(null)），另一个接收（take()），完成一次握手
底层怎么做到“直接交付”？
核心靠一个共享的栈或队列结构（公平/非公平对应不同实现），记录等待的线程节点。当一个线程执行 put()，它会把自己包装成“生产者节点”入栈并挂起；若此时已有“消费者节点”在等，就直接唤醒对方，把数据从当前线程栈拷贝过去，双方各自继续执行——整个过程不经过堆内存中转，也不经过中间容器。
- 无对象复制开销：数据引用直接传递，不是复制一份存起来
- 无内存泄漏风险：只要配对成功，线程和数据引用都会及时释放
- 失败时自动清理：超时或中断时，节点会被移除，避免残留等待线程
使用时要注意什么？
它强大但敏感，稍不注意就导致死锁或不可预期阻塞：
- 永远不要只写
put()不配take()，或反过来，否则必阻塞 - 慎用于不确定配对时机的场景，比如网络请求响应时间波动大，可能让一方长时间挂起
- 调试困难：线程堆栈里常看到
SynchronousQueue$TransferStack.transfer()，说明卡在匹配环节 - 替代方案考虑：若需缓冲，改用
LinkedBlockingQueue(1)或ArrayBlockingQueue
它不是万能队列，而是专为“即时交接”而生的线程间轻量级信道。用对了，简洁高效；用错了，容易卡住整个流程。
