exchanger 不适合用于多级评论区后端异步刷新，因其设计为双线程配对阻塞交换，主线程调用 exchange() 后若另一方未就绪将无限等待，导致容器线程池耗尽而假死。
Exchanger 不适合用于多级评论区的后端异步刷新模块，强行使用会直接导致主执行线程假死——这不是配置问题，而是设计误用。
为什么 Exchanger 会引发主执行线程假死
Exchanger 是 Java 并发包中专为两个线程之间一对一交换数据设计的同步工具。它要求成对线程必须同时到达 exchange() 点才能完成交换；任一线程先到，就会阻塞等待另一方，且无超时机制（除非显式调用带 timeout 的重载方法）。在评论异步刷新场景中：
- 刷新请求由 Web 容器线程（如 Tomcat 的 NIO 线程）发起，属于短生命周期、高并发、不可阻塞的主线程
- 若错误地让该线程调用 exchanger.exchange(data)，而配套的“另一方”线程（比如某个固定工作线程）尚未就绪或已退出，主线程将无限期挂起
- 多个此类请求堆积，迅速耗尽容器线程池，整个 HTTP 接口表现为“卡住”“无响应”，即典型的全局主执行线程假死
常见误用场景还原
开发者常因以下理解偏差引入 Exchanger：
- 误以为“线程间传数据”就该用 Exchanger，混淆了它与 BlockingQueue、CompletableFuture 或线程池 submit() 的语义边界
- 试图用 Exchanger 实现“评论提交 → 刷新线程处理 → 返回结果”的同步桥接，却未意识到这本质是单向异步任务分发，不是双向配对协作
- 在 Spring @Async 方法中嵌套调用 exchanger.exchange()，导致底层线程池中的工作线程也陷入等待，进一步加剧资源锁死
正确替代方案
针对多级评论异步刷新，应放弃 Exchanger，改用真正适配异步模型的机制：
- 用 CompletableFuture.supplyAsync()：封装刷新逻辑为异步计算任务，主线程立即返回，结果通过 thenAccept() 或异常回调处理
- 投递至线程池 + 回调通知：使用 ThreadPoolExecutor 提交刷新任务，完成后通过消息队列（如 RabbitMQ）或 WebSocket 主动推送刷新结果给前端
- 事件驱动架构：评论写入后发布 CommentPostedEvent，由独立的 RefreshCommentListener 监听并异步执行，完全解耦主流程
故障快速定位方法
若已出现假死，可结合以下方式确认是否为 Exchanger 导致：
- jstack 输出中查找大量线程处于 WAITING on java.util.concurrent.Exchanger$Node 状态
- 检查代码中是否存在非成对、非受控的 exchange() 调用，尤其关注是否在 Controller 层或 Filter 中直接使用
- 禁用相关模块后观察线程池活跃度和接口响应是否恢复，再逐段启用验证
