SynchronousQueue 无存储结构，size() 恒为 0，任务必须即时移交：有空闲线程则交付，否则立即创建新线程；offer() 失败触发扩容，put() 则阻塞等待配对线程。
SynchronousQueue 的无存储特性是理解线程池“即时移交”调度逻辑的关键入口——它不缓存任务，只充当线程间握手的同步点。任务提交那一刻，不是“存进去等取”，而是“必须当场找到接收方”。这种强同步语义直接决定了 newCachedThreadPool 等线程池的行为边界：有空闲线程就交过去，没有就立刻创建新线程，中间不留任何缓冲余地。
为什么 size() 永远是 0？这不是 bug，是设计契约
SynchronousQueue 根本没有内部数组、链表或任何容器结构来持有元素。调用 put() 时，当前线程会阻塞，直到另一个线程恰好在调用 take()；反之亦然。它不“存”，只“转”。所以：
- size() 恒为 0、isEmpty() 恒为 true，是自然结果，不是缺陷
- peek() 和 iterator() 直接抛 UnsupportedOperationException，因为根本无内容可查
- 监控中看到 queue.size() == 0，说明运行正常；若误以为“队列空了要告警”，反而会掩盖真实问题
offer() 与 put() 的语义分叉：决定任务是否触发扩容
在线程池 execute() 流程中，关键一步是尝试把任务交给空闲线程：
- queue.offer(task) 是非阻塞试探：没线程正在等待 take，就立刻返回 false —— 这个“失败”是正常控制流，触发 addWorker() 创建新线程
- queue.put(task) 是强同步移交：必须等到有线程调用 take 才返回，适用于需要严格配对的场景（如信号同步），但线程池内部不用它
- 别混淆 offer(task, timeout, unit)：在 SynchronousQueue 中，它和 put 行为一致，超时前仍需匹配消费者，不是“尽力插入”
任务卡住？问题不在队列，而在“谁在等、谁在取”
由于没有缓冲，任务无法“排队待命”。一旦 submit 后没立刻执行，原因只能是：
- 没有空闲线程正在调用 take()（比如所有线程都阻塞在 I/O、锁、GC 或长耗时计算中）
- 线程虽存活但处于 WAITING/TIMED_WAITING 状态，未进入任务获取循环
- 拒绝策略被触发（例如用了 AbortPolicy 且 offer 失败后又没扩容成功）
- 注意公平模式（TransferQueue）和非公平模式（TransferStack）的匹配顺序差异：后者可能让新任务优先被刚空闲的线程抢走，不按提交顺序
对比其他队列：看清“无缓冲”带来的行为跃迁
换成常见队列，线程池逻辑就彻底改变：
- 用 LinkedBlockingQueue（无界）：任务全进队列堆积，线程数永远卡在 corePoolSize，背压藏在内存里，OOM 风险高
- 用 ArrayBlockingQueue（有界）：队列满后才扩容，任务延迟不可控，还可能触发拒绝策略
- 而 SynchronousQueue 把背压外显为“是否新建线程”，让资源伸缩更透明、响应更及时
- 它的内存开销为 0 字节/任务，吞吐量（12.3M ops/s）和延迟（0.8μs）也明显优于带缓冲队列
