Exchanger仅适用于同一JVM内两个线程间的数据交换，因其依赖共享内存和线程调度，无网络通信、序列化、超时重试及跨进程能力，故不能用于分布式节点间的心跳对调。
Java 的 Exchanger<V> 是一个线程安全的同步器，用于**同一 JVM 进程内的两个线程**在指定汇合点交换数据。它不涉及网络、序列化、重试或跨进程通信能力，因此无法直接用于两个分布式节点（例如两台不同机器上的 Java 应用）之间的心跳对调。
为什么 Exchanger 不适用于分布式场景
• 它依赖共享内存和线程调度，两个参与方必须是同一个 JVM 中的两个线程；
• 没有网络传输能力，不封装 socket、HTTP 或 RPC 调用；
• 无超时重试、连接管理、序列化/反序列化逻辑；
• 分布式节点间存在网络延迟、分区、丢包等现实问题，Exchanger 完全不处理这些。
分布式心跳对调的合理替代方案
若目标是让两个服务节点定期交换轻量级状态（如时间戳、健康标识、版本号），推荐以下方式：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
• 使用 HTTP REST 接口（如 Spring Boot 的 @GetMapping("/heartbeat")），双方定时发起 GET 请求并解析 JSON 响应；
• 基于轻量级 RPC 框架（如 gRPC、Apache Dubbo 的泛化调用）定义 HeartbeatExchange 方法；
• 利用消息队列（如 Kafka/RocketMQ）各启一个消费者+生产者，通过 Topic 订阅/发布心跳快照；
• 若已有注册中心（如 Nacos、Eureka），可复用其心跳上报机制 + 自定义元数据字段实现双向感知。
如果坚持“类 Exchanger 语义”，可自行封装简易协议
模拟“双方同时发、同时收”的语义，需自行处理：
• 双方约定固定端口与路径（如 POST /api/exchange）；
• 请求体为 JSON（如 {"ts":1717023456789,"status":"UP"}），响应体为对方发来的同等结构数据；
• 客户端使用 HttpClient 同步调用，设置合理超时（如 3s）；
• 服务端收到请求立即返回当前本地心跳数据（不等待对方），实现“单向发 + 单向收”的对称交互。
这种设计不是 Exchanger，但能达成“双方周期性互换状态”的业务目标，且足够轻量、可控、可观测。
