Java 中 Exchanger 如何避免数据交换时的死锁问题

你可能会觉得，Exchanger 这个工具在 Java 并发包里有点小众，但用它的时候可别掉以轻心。它本身虽然不会搞出传统意义上的死锁——就是那种多个线程互相等对方释放资源的循环等待——但它有个更隐蔽的坑：单边永久阻塞。说白了，就是一个线程傻傻地卡在 exchange() 上，无限期地等另一个线程来配对，而对方可能因为异常、跳过了调用、跑偏了，甚至压根就没启动，根本不会出现。这种“假死”状态，比死锁更让人头疼。

所以，避免这类问题的关键，不是防死锁，而是防失配、保响应、控生命周期。下面这几个方向，是实践中反复验证过的。

必须使用带超时的 exchange 方法

无参的 exchange(V x) 方法，简直就是风险源。一旦配对失败，线程就直接挂起，没有任何回旋余地。强制替换成带超时的版本：

• exchange(V x, long timeout, TimeUnit unit) —— 超时后抛出 TimeoutException，线程可以及时清理、重试，或者降级处理。
• 超时值一定要贴合业务场景。比如双缓冲切换，设个 1 到 3 秒就够了；实时任务反馈，500 毫秒比较合适。千万别设成 30 秒以上，更别用 Long.MAX_VALUE，那还不如用无参方法。
• 捕获到 TimeoutException 后，建议记录日志、触发告警，并明确后续行为：是丢弃数据、返回默认值，还是直接关闭当前工作流。这一步很关键，不能忽略。

确保两个线程严格成对执行 exchange

Exchanger 的设计契约很明确：只能且必须两个线程参与。常见的破约情形包括：

• 某个线程因为条件不满足（比如任务取消、输入为空），直接跳过了 exchange() 调用。
• 第三个线程误调用了同一个实例，导致前两方无法配对，新来的也陷入等待。
• 线程启动不同步：一方已经超时退出，另一方才开始执行 exchange()。

建议的做法是：用 CountDownLatch 或启动协调器，统一控制双方进入交换点。同时，把交换逻辑封装在 try-finally 块里，确保无论成功失败，都能完成必要的清理操作。

配合中断机制增强可控性

exchange() 原生响应线程中断：被中断时会立即抛出 InterruptedException。这为外部干预提供了出口：

• 上层可以调用 thread.interrupt() 主动唤醒阻塞中的线程。
• 在 catch InterruptedException 之后，别忘了恢复中断状态：执行 Thread.currentThread().interrupt()。
• 如果线程正处于长时间任务中，需要定期检查 Thread.currentThread().isInterrupted()，并主动退出。

评估是否真需要 Exchanger

最后，还要反问一句：这个场景真的适合用 Exchanger 吗？如果存在以下特征，用它反而会增加复杂度和风险：

• 配对关系不固定，比如多生产者/消费者、动态线程池。
• 容错要求高，不能接受任一线程失败导致另一方卡住。
• 需要支持超时、重试、背压或广播等扩展能力。

这时候，更适合换成 SynchronousQueue（支持多线程配对+超时）、TransferQueue，或者基于 CompletableFuture 的异步协作模式。工具是死的，场景是活的，别为了一点方便，给自己埋雷。