Netty 如何实现心跳和空闲连接检测？

简化版

Netty 用 IdleStateHandler 检测连接的空闲状态——它能在指定时间内没有读事件（读空闲）、没有写事件（写空闲）、或读写都没有（读写空闲） 时，触发一个 IdleStateEvent（通过 userEventTriggered 回调）。业务收到空闲事件后决定动作：客户端通常在「写空闲」时发一个心跳 ping，服务端通常在「读空闲」超时后关闭连接（或连续几次没收到心跳再断）。心跳的作用是及时发现半连接、网络断开、对端崩溃，清理无效连接。间隔、超时、误判策略要结合业务设计。

详细版

IdleStateHandler 的三类空闲：

空闲类型	含义	典型用途
读空闲（readerIdle）	一段时间没收到数据	服务端：超时关连接
写空闲（writerIdle）	一段时间没写出数据	客户端：触发发 ping
读写空闲（allIdle）	两边都没活动	综合判断

用法：

pipeline.addLast(new IdleStateHandler(0, 30, 0));   // 30 秒写空闲
pipeline.addLast(new HeartbeatHandler());

class HeartbeatHandler extends ChannelInboundHandlerAdapter {
    @Override
    public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {
        if (evt instanceof IdleStateEvent e && e.state() == IdleState.WRITER_IDLE) {
            ctx.writeAndFlush(PING);   // 写空闲，发心跳
        }
    }
}

和 TCP KeepAlive 的区别：TCP KeepAlive 是操作系统层机制（默认间隔往往几小时），只探测「链路是否通」；应用层心跳可自定义间隔和内容，更适合服务治理。

完整版教学

一、为什么需要心跳

TCP 连接可能因为各种原因**「表面还在、实际已断」——变成半连接**：NAT 超时踢掉映射、网络切换（Wi-Fi↔4G）、对端进程崩溃、中间设备断链。这些情况下，应用层可能长时间感知不到——连接对象还在，但发数据对端收不到、也不会有明确的断开通知。

心跳就是定期发一个小消息确认「对端和链路是否仍然可用」，让系统及时发现无效连接并清理（释放资源、触发重连）。没有心跳，服务端可能积累大量「僵尸连接」，浪费资源。

二、IdleStateHandler 的三类空闲

IdleStateHandler 构造参数是三个时间：(readerIdleTime, writerIdleTime, allIdleTime)，分别对应三类空闲：

读空闲（READER_IDLE）：指定时间内没有收到任何数据。服务端常关注读空闲——如果一段时间没收到客户端的任何数据（包括心跳），说明客户端可能断了，可以关闭连接。
写空闲（WRITER_IDLE）：指定时间内没有写出任何数据。客户端常用写空闲触发 ping——如果一段时间没给服务端发数据，主动发个心跳，防止连接被 NAT/服务端判定为空闲踢掉。
读写空闲（ALL_IDLE）：读和写都没活动。

达到空闲时间，IdleStateHandler 会触发 IdleStateEvent，通过 userEventTriggered 回调传给后面的 Handler。

空闲类型	触发条件	常见动作
读空闲	指定时间没有读到任何数据	服务端累计 missed pong，超限关闭
写空闲	指定时间没有写出任何数据	客户端发送 ping 或心跳包
读写空闲	指定时间既没有读也没有写	做兜底保活或空连接清理

三、心跳协议怎么设计

心跳消息的设计要点：

轻量：心跳包要小、可快速识别，不能触发复杂业务逻辑。高连接数下（几十万连接），如果每个心跳都走重业务链路，心跳本身就成了巨大负担。
可识别：常见设计是 ping/pong（一方发 ping、另一方回 pong），带上协议版本或连接标识，便于处理。
不走重业务链路：心跳应该在协议层就被识别和处理，不进入业务逻辑。

pipeline.addLast(new IdleStateHandler(60, 30, 0, TimeUnit.SECONDS));
pipeline.addLast(new HeartbeatHandler()); // 处理 IdleStateEvent，发送 ping 或关闭连接

IdleStateHandler 检测的是“有没有读写事件”，不是业务在线状态；心跳能证明链路近期可达，但不能证明用户一定还在业务层在线。

四、超时时间如何设置

心跳间隔和超时的权衡：

间隔太短 → 浪费网络和 CPU（尤其海量连接）。
间隔太长 → 延迟发现故障（连接断了很久才知道）。

不同网络环境策略不同：移动网络（NAT 超时短、易切换）间隔要短些、跨公网连接、内网长连接各有不同。

重要经验：允许连续几次心跳失败后再断开——比如「连续 3 次没收到 pong 才判定断连」，而不是「一次超时就断」。这样能降低短暂网络抖动导致的误杀（一次抖动不代表真断了）。

五、和 TCP KeepAlive 的区别

TCP KeepAlive 是操作系统层的保活机制，很多人拿它和应用层心跳混淆，区别：

TCP KeepAlive：OS 层，默认间隔往往很长（Linux 默认 2 小时），语义不包含业务状态（只探测 TCP 链路是否通），且很多中间设备可能不透传。
应用层心跳：可自定义间隔和内容，能携带业务信息，更适合服务治理（快速发现、精细控制）。

两者可以同时存在，但不要混为一谈——实际项目基本靠应用层心跳，因为 TCP KeepAlive 太慢、不够灵活。

六、Pipeline 放置位置

IdleStateHandler 通常放在业务 Handler 前面，这样它能观察到读写事件、并在空闲时触发 userEventTriggered。心跳处理 Handler 放在它后面，收到 IdleStateEvent 后发 ping 或关闭连接。注意异常路径要释放资源（ByteBuf release）。

七、排查误判

心跳频繁超时，不一定是网络真的断了——还可能是：

EventLoop 被阻塞（慢 Handler 拖住线程，心跳的读写和定时任务都被延迟，见「EventLoop」专题）。
GC 停顿（Full GC 导致 STW，期间处理不了心跳）。
下游写缓冲堆积（心跳包排在大量待写数据后面，发不出去，见「背压」专题）。
心跳包被业务解码器误处理。

所以排查心跳误判要同时看线程（jstack）、GC、写队列、网络——别一看心跳超时就以为是网络问题。

八、心跳只能说明链路可达，不代表业务在线

一个重要认知：心跳只能说明「链路在某个时刻可达」，不代表「用户仍然在线、会话仍有效、业务订阅仍存在」。

对 IM、推送、网关这类系统，判断「连接/用户是否在线」不能只靠 TCP 连接是否存在——还要结合登录态、最后活跃时间、设备标识、重连策略综合判断。因为：

网络切换时，旧连接可能还没被检测到断开，新连接已经建立（多个连接并存）。
多端登录时，一个用户有多个连接。

只用「TCP 连接是否存在」代表业务在线，会在网络切换和多端登录场景出错——连接活着不等于业务状态有效。

九、常见误区与追问

误区：心跳等同于 TCP KeepAlive。 TCP KeepAlive 是操作系统层的长周期探测，应用心跳能携带业务语义并按业务秒级阈值控制。
误区：一次读空闲就必须立即断开。 生产环境通常会累计连续失败次数，避免网络抖动或短暂停顿导致误杀连接。
误区：心跳成功就说明用户业务在线。 心跳只说明连接层近期可达，业务在线还要结合登录态、会话和最后活跃时间。
追问：IdleStateHandler 应该放在 Pipeline 什么位置？ 通常放在业务 Handler 前，让空闲事件能先被触发和处理，再决定是否发送心跳或关闭。
追问：为什么 EventLoop 阻塞会导致心跳误判？ 空闲检测和心跳处理也在 EventLoop 上执行，线程被阻塞时读写事件和定时事件都会延迟。
追问：服务端和客户端心跳职责有什么区别？ 客户端常用写空闲主动发 ping，服务端常用读空闲检查是否持续收不到客户端数据或 pong。

十、加强记忆

Netty 用 IdleStateHandler 检测读空闲/写空闲/读写空闲，空闲时触发 IdleStateEvent（userEventTriggered 回调）。典型：客户端「写空闲」发 ping、服务端「读空闲」超时关连接（或连续几次没心跳再断，降低抖动误杀）。心跳作用：及时发现半连接（NAT 超时/网络切换/对端崩溃）并清理。心跳协议要轻量、ping/pong、不走重业务链路（海量连接时）。vs TCP KeepAlive：后者是 OS 层、默认间隔很长、不含业务语义，实际靠应用层心跳。放 Pipeline 业务 Handler 前。心跳误判排查看 EventLoop 阻塞/GC/写队列/网络（别只怪网络）。心跳只说明链路可达 ≠ 业务在线——IM/推送要结合登录态/活跃时间/设备标识（防网络切换、多端登录出错）。

简化版

详细版