exchanger 仅适用于严格双线程配对场景，误用于多线程或虚拟线程会导致严重性能劣化；必须使用带超时的 exchange(v, timeout, unit)，避免阻塞；禁止在 exchange 内执行耗时操作；其优势仅存在于低延迟高频双线程交换场景。
Exchanger 在多线程协作中不是为“多线程”设计的，它的性能损耗根源不在实现低效，而在于误用场景引发的系统级反效果——当把它放进非双线程配对的协作模型里，性能会急剧劣化，甚至比加锁还差。
它天生只服务两个线程
Exchanger 的契约非常严格：必须且仅需两个线程同时到达 exchange() 点，才能完成一次原子交换。它不排队、不缓存、不记身份、不支持重试或转发。
- 第三个线程调用
exchange()会无限等待，直到有另一个线程来配对 - 若线程 A 异常退出，线程 B 就永远卡在
TIMED_WAITING状态 - 在线程池中复用同一个 Exchanger 实例，上一轮的配对关系完全丢失，协作逻辑断裂
这种机制在真实系统中极易导致“配对失衡”：比如 1000 个虚拟线程并发调用 exchanger.exchange(data)，实际成功交换的可能不到 20%，其余全部阻塞或超时，内存占用飙升，调度开销陡增。
超时缺失是性能雪崩的导火索
无超时的 exchange(V) 在生产环境等同于埋雷。网络抖动、GC 暂停、I/O 延迟都可能导致配对延迟几十毫秒以上，而一个线程卡住，就会拖慢整个协作链。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 不设超时 → 线程长期阻塞 → 线程池耗尽 → 新任务排队 → 响应延迟激增
- 超时设置过长（如 30 秒）→ 表面可用，实则掩盖配对失败问题，监控难发现
- 正确做法是：用
exchange(V, timeout, unit)，超时后立即释放资源、上报指标、触发降级
数据与操作越重，放大效应越明显
exchange() 是同步点，不是执行点。它本身纳秒级完成，但若把耗时逻辑塞进去，就会污染配对行为：
- ✅ 先填充缓冲区 → 再
exchange(buffer) - ❌ 在
exchange()内部读文件、解析 JSON、触发 Full GC
后者会让配对线程被迫等待，不仅自身延迟升高，还会拉高对方线程的等待时间，形成恶性循环。
和虚拟线程搭配反而拖累吞吐
Exchanger 的“强配对”语义与虚拟线程“松耦合、高密度、可伸缩”的设计目标直接冲突。
- 虚拟线程本意是让 I/O 密集型任务轻量挂起/恢复
- Exchanger 却强制它们“手拉手站队”，稍有节奏偏差就大量线程堆积在等待队列
- 测试显示：10,000 个虚拟线程跑 Exchanger，吞吐不升反降，内存占用翻倍，GC 频率显著上升
它和 BlockingQueue 或 Phaser 相比，优势只存在于严格双线程、低延迟、高频切换的场景（如双缓冲帧交换）。一旦脱离这个边界，性能优势立刻反转。
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
