SynchronousQueue 不支持 offer() 或 poll() 是因其设计为线程间“手递手”交接通道，非阻塞操作必然失败；公平模式仅影响等待线程的配对顺序，不改变数据语义；与 LinkedTransferQueue 混用易因 transfer() 语义差异导致并发控制失效；线程池中使用时拒绝策略尤为关键，因无缓冲会立即触发拒绝。
为什么 SynchronousQueue 不能用 offer() 或 poll() 异步操作？
它根本不是用来“存数据”的队列，而是两个线程之间“手递手”交接的通道。调用 put() 的线程会一直阻塞，直到另一个线程恰好在同时调用 take()；反过来也一样。offer() 和 poll() 这类非阻塞方法，在没有配对线程时立刻返回 false 或 null，几乎总失败——这不是 bug，是设计使然。
- 适合场景：生产者-消费者严格一对一、低延迟要求（比如线程池中直接移交任务）
-
offer(e, timeout, unit)和poll(timeout, unit)可用，但本质仍是等待配对，超时即放弃 - 误当普通队列用会导致大量线程空转或假死，尤其在压力不均时
SynchronousQueue 的公平性参数到底影响什么？
构造时传 true 表示启用公平模式（FIFO），false（默认）用非公平的栈结构。区别不在“谁先拿到数据”，而在“谁先等到配对”。非公平模式下，后到的线程可能插队抢到先到者的配对机会，导致饥饿；公平模式则按等待顺序匹配，但吞吐略低。
- 公平模式：适用于对响应时间一致性有要求的场景（如实时任务分发）
- 非公平模式：吞吐更高，但个别线程可能长时间等不到配对
- 这个参数不影响数据内容或线程身份，只影响等待队列的调度逻辑
和 LinkedTransferQueue 混用时容易踩哪些坑？
两者都支持 transfer()，但语义不同：SynchronousQueue.transfer() 必须等待配对，而 LinkedTransferQueue.transfer() 在有积压时会直接入队。如果代码里假设“transfer 就一定阻塞”，换成后者就可能漏掉阻塞逻辑，导致任务悄无声息进队列，破坏预期的同步行为。
- 错误现象：
transfer()在LinkedTransferQueue中不阻塞，但开发者以为它会，结果并发控制失效 - 迁移时必须检查所有
transfer()调用点是否依赖“绝对阻塞”语义 -
SynchronousQueue没有容量概念，LinkedTransferQueue默认无界，内存占用风险完全不同
线程池用 SynchronousQueue 时，拒绝策略为何特别关键？
当核心线程全忙，且没有空闲线程可接手新任务时，submit() 会直接触发拒绝策略——因为 SynchronousQueue 不缓存任何任务。哪怕只是瞬时高峰，也会立刻丢任务，不像 ArrayBlockingQueue 那样还能撑几把。
立即学习“Java免费学习笔记（深入）”；
- 默认
AbortPolicy抛RejectedExecutionException，线上易被忽略 - 用
CallerRunsPolicy可缓解，但会把任务回退给调用线程执行，可能拖慢上游 - 务必确认监控能捕获拒绝事件，否则系统降级时连告警都没有
