TransferQueue 是强制“手递手”交付的队列，适用于RPC绑定、任务委派等需零缓冲低延迟场景；非必需时勿替代BlockingQueue，否则易致阻塞和吞吐暴跌。
TransferQueue 是什么，什么时候非用它不可
TransferQueue 不是 BlockingQueue 的升级版，而是另一条路：它强制“手递手”交付——生产者不把元素塞进队列就卡住，直到消费者来取走。这在需要严格配对、零缓冲、低延迟响应的场景才真正有用，比如 RPC 请求-响应绑定、任务委派后必须等结果、或者资源池中对象的即拿即用。
常见错误现象是：用 TransferQueue 替代 LinkedBlockingQueue 做普通异步日志收集，结果线程大量阻塞，吞吐暴跌。这不是它设计的目标。
- 如果你只是要“存起来以后再处理”，用
BlockingQueue更稳 - 如果你要求“这个任务必须被立刻接手，否则我不发”，
TransferQueue才是解 - 它天然排斥背压丢失：没有消费者时，
transfer()会阻塞或超时失败，不会默默丢数据
transfer() 和 tryTransfer() 的行为差异很关键
transfer() 是核心操作，但它不是“插入”，而是“移交”。调用后线程会挂起，直到另一个线程调用 take() 或 poll()（带超时）来接走这个元素。
tryTransfer() 则试探性移交：有消费者在等待就立刻成交；没人等着就直接返回 false，不阻塞。
使用场景决定选哪个：
- 实时指令下发（如设备控制指令），必须确保有人立刻响应 → 用
transfer()，配合超时避免永久卡死 - 异步事件广播，允许“没人听就放弃” → 用
tryTransfer() - 注意：
tryTransfer(E e, long timeout, TimeUnit unit)的 timeout 是“等消费者出现”的时间，不是“等消费者处理完”的时间
SynchronousQueue 其实是 TransferQueue 的特例
SynchronousQueue 是 JDK 自带的 TransferQueue 实现，但它不存储任何元素——连一个槽位都没有。所有 put() 都必须匹配一个并发的 take()，否则阻塞。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
容易踩的坑：
- 把
SynchronousQueue当作轻量级队列用，结果发现size()永远是 0，peek()永远返回null - 在单线程里先
put()再take()，必然死锁（没第二个线程来配对） - 它的公平模式（构造时传
true）会按 FIFO 排队移交请求，但性能比非公平模式低 20%+，仅在需要严格顺序时启用
LinkedTransferQueue 的实际性能和兼容性陷阱
LinkedTransferQueue 是唯一带内部队列的 TransferQueue 实现：没人等时，元素先暂存；有人等时，直接交接，跳过入队出队。
但它不是万能润滑剂：
- 在高争用下，它的 CAS 开销比
ArrayBlockingQueue高，尤其当多数操作是“有缓冲的普通 put/take”时，性能反而更差 - Android 7.0（API 24）之前不支持
LinkedTransferQueue，反射调用会抛NoClassDefFoundError -
transfer()超时后，元素仍留在队列里（已入缓冲区），这点和SynchronousQueue完全不同，容易误判“操作失败=数据丢了”
真正难处理的是混合模式：一部分逻辑依赖即时移交，另一部分只关心最终消费。这时候得拆成两个队列，或者用状态标记 + 显式超时回调，别指望一个 TransferQueue 全包。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
