“局部连接对象泄漏”指心跳超时配置缺失导致特定模块（如WebSocket会话表、Netty ChannelGroup）中失效连接未被清理，表现为活跃连接数异常攀升、新连接变慢、偶发Too many open files错误；须通过IdleStateHandler检测、双向心跳、生命周期监听与ID打点日志闭环修复。
心跳超时配置缺失，会导致连接对象在逻辑上已失效、物理上却未断开，客户端或服务端持续持有该连接引用，却不主动清理——这就是“局部连接对象泄漏”的本质。
为什么叫“局部”泄漏？
它不表现为整个进程内存暴涨或文件描述符全局耗尽，而是特定于某类连接管理模块的内部状态失控。比如：
- Netty 的
ChannelGroup中某个 Channel 状态卡在ACTIVE，但实际已无响应； - WebSocket 服务端的会话映射表（如
Map<sessionid session></sessionid>）里仍存着一个无法通信的 Session； - 自研连接池中，该连接被标记为“空闲”，但后续获取时因无心跳校验直接返回，导致业务协程阻塞或静默失败。
心跳缺失如何触发泄漏？
没有心跳机制或心跳超时未设，系统就丧失了判断连接是否存活的能力：
- NAT/防火墙在 30–60 分钟后悄然回收连接，但服务端毫不知情，仍把它当有效连接维护；
- 客户端因休眠、切网、进程后台挂起等场景中断收发，服务端既没收到 close 帧，也无 ping 超时事件，连接句柄一直留在内存里；
- 应用层未设置
IdleStateHandler或 WebSocket 的pingTimeout，导致 Netty 或容器无法触发userEventTriggered回调来释放资源。
泄漏后果往往滞后且隐蔽
单个泄漏影响微小，但随时间推移会逐步暴露：
- 连接数缓慢爬升，监控显示“活跃连接数 > 在线用户数 × 1.5”，提示存在僵尸连接；
- 新连接建立变慢，因为 select/epoll 需遍历大量无效句柄；
- 偶发
Too many open files错误，尤其在 Linux 上受限于ulimit -n； - GC 日志中频繁出现
Finalizer队列堆积，说明连接底层 Socket 对象迟迟未被回收。
关键修复动作
不是加个定时 ping 就完事，要形成闭环：
- 服务端必须启用带超时的 Idle 检测（如 Netty 的
IdleStateHandler(30, 0, 0, TimeUnit.SECONDS)），并在USER_EVENT中主动close()； - 客户端需双向心跳：既要发 ping，也要校验 pong 是否在约定窗口内到达；
- 所有连接对象须绑定生命周期监听器，在关闭前清除其在业务上下文（如用户 session 映射、消息路由表）中的引用；
- 配合连接唯一 ID 打点日志，一旦发现某 ID 连续 2 次心跳超时，立即记录并告警，避免靠猜定位泄漏点。
