linkedtransferqueue的transfer()方法不用于变量交换，其核心语义是“等待消费者取走元素”，属单向同步交付，无双向数据交换能力。
LinkedTransferQueue 的 transfer() 方法不用于变量交换，也不支持“直接交付”意义上的值传递或变量赋值。它是一个阻塞式、无界、线程安全的队列，transfer() 的核心语义是“等待消费者取走元素”，而非在两个线程间交换变量值。
transfer() 的真实行为：生产者与消费者同步交接
调用 transfer(e) 时：
- 如果当前有等待中的消费者（即已调用
take()或poll(long, TimeUnit)并阻塞），则立即将元素e交给该消费者，方法立即返回； - 如果没有等待的消费者，当前线程会**阻塞**，直到有另一个线程调用
take()或带超时的poll()来取走该元素； - 它不是“交换”——不读取、不修改、不返回对方的数据，也不要求调用方同时提供“自己的值”来换。
为什么它不能用于变量交换
变量交换（如两个线程交换各自持有的 int 值）需要双向数据流动和协调机制，而 transfer() 是单向的“交付-取走”模型：
- 没有对称操作：没有
receive()或swap()配套方法； - 不返回对方的数据：生产者只传入一个值，不接收任何返回值；
- 无法保证配对：多个
transfer()调用可能被同一个take()消费，无法绑定特定线程对。
若需线程间交换值，应使用更合适的工具
例如：
-
Exchanger
：专为两个线程协作交换对象设计，双方调用 exchange(v)后自动配对并互换值； -
SynchronousQueue：类似
LinkedTransferQueue的“手递手”语义，但更轻量，也支持put(e)+take()实现单次同步交付（仍非交换）； - 自定义基于
Lock+Condition的双缓冲交换结构（仅在特殊场景下必要）。
小结：别混淆“交付”与“交换”
LinkedTransferQueue.transfer() 解决的是“我有东西，等你来拿”的同步问题；而变量交换解决的是“我出 A，你出 B，我们互换”的协作问题。二者目标不同、API 设计不同、适用场景也不同。强行用 transfer() 模拟交换，会导致逻辑复杂、易出错且违背其设计初衷。
