LinkedTransferQueue 的核心价值在于融合缓冲与即时配对：通过双重队列设计，以数据节点（isData=true）和请求节点（isData=false）实现“能存又能等”，全程无锁（CAS+自旋+LockSupport），匹配成功零拷贝，未匹配则自动入队，兼具高吞吐与低延迟。
LinkedTransferQueue 的核心价值在于它把 BlockingQueue 的缓冲能力与 SynchronousQueue 的“即时配对”语义融合在一个无锁、无界的数据结构里，不是简单叠加，而是用双重队列（Dual Queue）设计统一实现。
它怎么同时做到“能存”又“能等”？
关键在节点的两种身份：数据节点（isData = true）和请求节点（isData = false）。生产者调用 transfer() 时，不急着入队，而是先看队头——
- 如果队头是请求节点（说明有消费者在等），立刻匹配，元素直接交给对方，不经过队列存储；
- 如果队头是数据节点或空，就把自己包装成数据节点，追加到队尾，进入等待状态；
- 消费者调用
take()或transfer()时同理：先匹配头节点中的数据，匹配不上才生成请求节点入队。
为什么比 LinkedBlockingQueue 更轻量？
LinkedBlockingQueue 依赖两把独立锁（putLock 和 takeLock），虽支持并发出入，但仍有锁开销和内存屏障成本。LinkedTransferQueue 完全基于 CAS + 自旋 + LockSupport，没有显式锁：
- 所有节点链接、状态变更、线程挂起/唤醒都靠原子操作完成；
- 匹配成功时零拷贝、零队列中转，延迟趋近于函数调用；
- 即使未匹配，入队也只更新 tail 指针，无需锁保护整个链表结构。
它和 SynchronousQueue 的本质区别在哪？
两者都强调“传递”，但 SynchronousQueue 是纯配对、零容量——没配对就阻塞，且不保留历史请求。LinkedTransferQueue 是“带缓存的配对”：
- 当没有即时消费者时，
transfer()仍会把数据节点入队，后续消费者可直接取走，相当于有了隐式缓冲； -
hasWaitingConsumer()和getWaitingConsumerCount()可实时感知等待方，便于做流控或负载预判； - 支持
offer()、poll()等非阻塞操作，行为更接近通用队列，适用场景更广。
什么场景下该选它？
适合对吞吐和响应都有要求的多生产者-多消费者模型，尤其是消费者活跃度波动大、又不能丢数据的系统：
- 消息中间件中“推送+回执”通道，生产者希望尽快确认送达，而非只进缓冲区；
- 实时计算任务分发，Worker 启动慢或动态伸缩时，任务可暂存队列，避免拒绝或重试；
- 替代 SynchronousQueue 但又不愿承担“全阻塞即失败”的风险时，它提供了柔性退路。
