金融资产写业务严禁使用无超时的Exchanger，因其无限等待会导致线程阻塞、事务泄漏、资金操作挂起等严重风险；必须使用exchange(V x, long timeout, TimeUnit unit)并设合理超时值，超时后需记录日志、触发补偿或上报未知状态，且应隔离线程池与强化监控。

在大厂高频核心生产场景中，涉及金融资产的写业务严禁使用未配置安全超时防护的 Exchanger，根本原因在于：无限等待 = 不可控阻塞 = 金融级可用性与一致性双重风险。

这类业务对响应延迟、事务边界、失败可追溯性要求极高。而 Exchanger.exchange(V x) 默认无限阻塞，一旦配对线程因 GC 暂停、调度延迟、逻辑异常或上游依赖超时未能及时抵达交换点，当前线程就会卡死，直接引发：

• 线程池资源耗尽（尤其在 Tomcat 或 Netty worker 线程中）
• 事务上下文泄漏（如 Spring 的 @Transactional 无法正常回滚）
• 账户余额更新挂起、资金划转停滞、对账中断
• 监控指标失真（如 P99 延迟突增、线程堆积告警失效）

这不是理论风险——真实故障案例中，曾有支付通道适配模块因 Exchanger 缺少超时，导致批量代付任务在 JVM Full GC 期间集体 hang 12 秒以上，触发风控熔断并造成短时资损误判。

必须启用带超时的 exchange 方法

永远使用重载签名：exchange(V x, long timeout, TimeUnit unit)，禁用无参版本。

• 超时值不能拍脑袋定：需结合该链路 SLO（如金融写操作 P99 ≤ 800ms），建议设为 1.5 × P99 + 网络毛刺缓冲（如 200ms）
• 单位务必显式指定 TimeUnit.MILLISECONDS，避免 TimeUnit.SECONDS 导致超时过长
• 超时后必须抛出业务可识别异常（如自定义 `ExchangeTimeoutException`），不得静默吞掉

超时不是终点，而是容错起点

捕获 TimeoutException 后，不可简单重试或返回默认值——金融写操作必须明确状态：

• 记录完整上下文日志（traceId、账户ID、金额、超时前已执行步骤）
• 主动调用补偿机制：如向消息队列投递「待确认」事件，由对账服务兜底核验
• 若处于分布式事务分支中，需向事务协调器上报「未知状态」，触发二阶段查证

线程模型与资源隔离必须前置设计

Exchanger 不是万能同步器，它天然绑定「严格两线程配对」语义。在高并发金融场景中：

• 禁止在 Web 容器主线程（如 Spring MVC 的 DispatcherServlet 线程）中直接调用 exchange
• 应封装为独立线程池任务（但须手动创建 ThreadPoolExecutor，禁用 Executors 工具类——避免无界队列 OOM）
• 建议为金融写链路划分专用线程池（如 `finance-exchange-pool`），并配置拒绝策略为 `AbortPolicy` + 自定义告警

监控与可观测性不可妥协

仅加超时不够，必须让超时行为“看得见、可归因”：

• 暴露 Prometheus 指标：`exchanger_timeout_total{operation="fund_transfer"}`
• 在 APM 中为每次 exchange 调用打上 span 标签，标记是否超时、配对线程名、实际等待耗时
• 设置超时率基线告警（如 5 分钟内 >0.1% 即触发 oncall）