transfer()方法不用于变量交换，其核心语义是“等待消费者取走元素”，仅保证交付完成而非处理完毕，返回时机取决于take()或带超时poll()的匹配，不感知后续消费逻辑。
transfer() 方法不用于变量交换，它确保的是“元素被消费者取走后才返回”，不是“被处理后”。关键区别在于：取走（take）≠ 处理（execute）。它只管交接是否完成，不管后续逻辑。
transfer() 的返回时机由“匹配成功”决定
调用 transfer(e) 后，方法是否返回，完全取决于是否有另一个线程正在或即将执行 take() 或带超时的 poll()：
- 若有等待中的消费者（已调用 take() 并阻塞），则 e 立即移交，transfer() 瞬间返回
- 若无等待消费者，当前线程生成一个“请求节点”（isData=false），插入队列尾部，并进入 WAITING 状态
- 当后续有线程调用 take()，它会扫描队列头部，发现该请求节点后，用 CAS 将其 item 字段设为 e，并唤醒生产者线程——此时 transfer() 才返回
它不感知、也不等待“消费行为”的发生
transfer() 的语义止步于“交付完成”，而非“任务执行完毕”：
- 消费者拿到元素后是立刻处理、延迟处理、还是丢弃，transfer() 完全不关心
- 没有回调、无状态跟踪、不记录消费进度；它只保证一次原子性的“手递手”移交
- 举例：Web 线程调用 queue.transfer(req)，审计线程 take() 拿到 req 后打印日志就返回了——transfer() 在 take() 返回那一刻就结束了，哪怕审计线程还没开始解析 req 内容
与真正“处理后确认”的方案对比
若业务需要“消费者处理完成后再通知生产者”，transfer() 无法单独满足，需额外协作：
- 可组合 CompletableFuture：消费者处理完后 complete() 一个 future，生产者 await
- 可用 CountDownLatch 或 Exchanger 实现双向同步，但需自行协调生命周期
- tryTransfer(E, timeout, unit) 只控制“等待消费者出现”的时长，不延长到处理阶段
为什么设计成这样？
这种轻量级交付模型是为了低延迟和零拷贝而生：
- 避免在队列中暂存大对象，减少 GC 压力
- 省去中间缓冲，数据直接从生产者栈帧传入消费者栈帧
- 匹配过程全程无锁，靠 CAS + 自旋 + 线程挂起/唤醒实现高并发吞吐
