exchanger.exchange(v) 方法会使线程立即进入 waiting 状态，无条件挂起等待配对线程；其内部采用单槽位状态机机制，先到线程被封装为等待者并调用 locksupport.park()，若配对线程永不出现，则该线程永久阻塞，导致资源雪崩与系统假死。
Exchanger.exchange(V) 方法表面看只是“交换数据”，实则是一张精密设计的同步等待网。一旦线程调用无参 exchange()，它不会尝试匹配、不设退路、不预留出口——而是直接进入 WAITING 状态，静候另一个线程现身配对。这不是延迟响应，而是主动交出执行权，陷入 JVM 级别的线程挂起。
为什么“先到即挂起”是必然行为
Exchanger 内部采用状态机+单槽位配对机制：同一时刻仅支持一对线程完成交换。当线程 A 先调用 exchange(v)，Exchanger 会立即将其封装为“等待者”，写入内部等待节点，并调用 LockSupport.park() 使其进入 WAITING。此时线程 A 不再消耗 CPU，也不再推进逻辑，完全依赖线程 B 的到来触发唤醒。
- 没有轮询、没有自旋、不检查超时——纯粹阻塞式协作
- 即使线程 B 永远不出现（如崩溃、逻辑跳过、条件未满足），线程 A 就永远停在 park 处
- JVM 线程 dump 中清晰显示为 java.lang.Thread.State: WAITING (parking)
这张“网”如何悄然收紧资源
看似轻量的等待，在高并发或异常场景下会迅速演变为资源雪崩：
- 线程池中若大量线程卡在 exchange()，可用工作线程锐减，新请求排队甚至拒绝
- 若 exchange 发生在 Servlet 容器线程（如 Tomcat）中，会直接拖慢整个 HTTP 请求吞吐
- 线程堆栈无法释放、本地变量持续持有、GC Roots 增加，间接推高内存压力
如何一眼识别这个陷阱
不需要运行代码，只需三秒扫描：
- 看到 exchange(x) 且无 timeout 参数 → 当前线程已承诺“无限等待”
- 该调用位于 try-catch 但只捕获 InterruptedException → 缺少对“永久失联”的防御
- 上下游无监控埋点（如计时打点、配对失败告警）→ 风险不可见、故障难定位
破网关键：用超时打破确定性阻塞
真正安全的写法不是避免使用 Exchanger，而是强制引入时间边界：
- 必须使用 exchange(V, long, TimeUnit)，超时值需结合业务 SLA 设定（如 80% 场景在 200ms 内完成，则设 500ms）
- 捕获 TimeoutException 后必须有明确降级路径：返回默认值、走异步补偿、记录告警日志
- 配合 Micrometer 或 Prometheus 对 exchange 超时率、平均等待时长做指标采集，设置 >1% 超时即告警
