Exchanger本身不管理TCP连接或缓冲区，仅是线程间交换数据的同步工具；所谓“配对失败导致TCP缓冲区耗尽”实为现象混淆，真正原因是底层TCP连接泄漏、无超时读写或socket未释放，Exchanger配对失败仅暴露并加剧了上层协作缺陷。
Exchanger 本身不管理 TCP 连接或缓冲区，它只是线程间交换数据的同步工具。所谓“因 Exchanger 配对失败导致 TCP 缓冲区物理内存耗尽”，其实是现象混淆——真正耗尽内存和卡死长尾连接的，是底层未受控的 TCP 连接行为（如连接泄漏、无超时读写、未释放 socket），而 Exchanger 的配对失败只是暴露了上层协作逻辑缺陷，间接加剧了资源滞留。
明确责任边界：Exchanger 不持有连接，也不分配缓冲区内存
Exchanger 是纯内存同步组件，运行在线程栈与堆中，不创建 Socket、不申请内核缓冲区、不打开文件描述符。它只在两个线程调用 exchange() 时做一次对象引用交换。所谓“TCP 缓冲区耗尽”，根源一定在：
• TCP 客户端/服务端代码中反复 new TcpClient 或未 close socket
• 异步推送模块中连接复用缺失、重连逻辑残缺、超时设置为 0 或 Integer.MAX_VALUE
• JVM 层面未限制连接池大小，或系统级本地端口被占满（TIME_WAIT 堆积）
切断 Exchanger 失败与连接泄漏的传导链
当异步推送模块用 Exchanger 协同“数据准备线程”和“网络发送线程”时，若一方崩溃、阻塞或未执行 exchange，另一方长期等待，就会造成：
- 数据准备线程持有一个待推送消息对象，无法释放，若消息含大 byte[] 或缓存引用，会堆积堆内存
- 网络发送线程空转等待，若它还持有着未 flush 的 SocketChannel 或未 dispose 的 TcpClient 实例，连接句柄与内核缓冲区持续占用
- 多个此类“半挂起”组合并发出现，最终表现为连接数飙升、TIME_WAIT 暴涨、
No buffer space available
解决关键不是给 Exchanger 加锁或重写，而是隔离同步逻辑与连接生命周期：
- 用带超时的
exchange(V, timeout, unit)，超时后主动丢弃本次推送任务，并触发连接健康检查 - 网络发送线程在 exchange 超时后，必须立即调用
tcpClient.Close()或channel.close()，不能等待 GC - 数据准备线程在 exchange 抛出 TimeoutException 后，应清空本地缓存、释放 ByteBuffer、取消关联的 pending request ID
强制连接资源受控的三道防线
针对长连接异步推送场景，仅靠 Exchanger 无法兜底，必须叠加以下机制：
-
连接层：单例 + 心跳 + 自动重建
每个目标地址（IP:Port）只维护一个 TcpClient 实例；每 15 秒发一次 Modbus Read UnitID 或 HTTP HEAD 探针；连续 2 次失败则标记失效并重建新连接，旧连接调用Dispose()并设为 null -
传输层：硬性超时 + 异步取消
设置TcpClient.SendTimeout = 400、ReceiveTimeout = 400（单位毫秒）；所有读写操作封装为Task.WithCancellation(cancellationToken)，exchange 超时即触发 cancel -
应用层：背压 + 限流 + 降级
推送队列使用有界 BlockingCollection（如容量 1024）；当队列满时，拒绝新推送请求并返回 429；极端情况下（如连续 5 次 exchange 超时），自动切换为批量轮询模式，暂停实时推送
验证是否真由 Exchanger 引发问题的快速方法
加两行日志即可定位：
- 在调用
exchange(..., 3, SECONDS)前打点：log.debug("push-{}: entering exchange", reqId) - 在 exchange 返回后立刻打点：
log.debug("push-{}: exchanged, size={}", reqId, data.length)
如果大量请求只打出第一行日志，且持续数分钟无第二行，则说明配对线程根本没走到 exchange —— 此时应查网络线程是否卡在 socket.read()、是否被异常吞掉、是否线程池已满。此时优化 Exchanger 无意义，要先修复线程调度或 I/O 阻塞点。
