idlestatehandler仅触发空闲事件，不自动关闭连接或发心跳；真正解决假死需在usereventtriggered中显式处理reader_idle等事件，否则连接持续占用资源。
IdleStateHandler 本身不关闭连接，也不自动发心跳——它只负责在读/写空闲超时后触发事件。能否真正解决假死，取决于你如何响应这些事件。直接加个 IdleStateHandler 而不配套处理逻辑，等于没做。
为什么 IdleStateHandler 加了但连接还是不释放？
常见现象是：服务端配置了 IdleStateHandler(60, 0, 0)，但客户端断连后，服务端的 Channel 仍长期处于 ACTIVE 状态，内存和文件描述符持续上涨。
根本原因在于：IdleStateHandler 触发 READER_IDLE 后，若未在 userEventTriggered 中显式关闭或清理，事件就“沉没”了。Netty 不会替你做任何资源回收动作。
- 必须自定义一个
ChannelInboundHandler或ChannelDuplexHandler，重写userEventTriggered - 判断
evt.state() == IdleState.READER_IDLE后，调用ctx.channel().close()或先发探针再关（见下一条） - 注意：不要在
userEventTriggered中执行阻塞操作，否则会卡住整个EventLoop
WRITER_IDLE 和 READER_IDLE 的使用场景差异
对网关类服务，READER_IDLE 是核心检测项；而 WRITER_IDLE 更适合客户端主动保活场景。
-
READER_IDLE：适用于服务端判断“这个客户端是不是挂了”。例如配置new IdleStateHandler(120, 0, 0)，表示 120 秒没收到任何数据包（包括心跳），就可视为假死 -
WRITER_IDLE：常用于客户端侧——比如移动端弱网环境下，客户端需定期向服务端发心跳，防止中间设备（如 NAT、防火墙）回收连接。服务端一般不依赖它做判定，因为无法区分是真沉默还是网络抖动丢包 - 慎用
ALL_IDLE：它要求“既没读也没写”，但在双向通信网关中，客户端可能只收不发（如推送场景），容易误判
心跳包怎么发才不会被当成业务流量干扰协议解析？
很多团队在 userEventTriggered 里直接 ctx.writeAndFlush(new PingMessage())，结果发现解码器报 InvalidFrameException——因为心跳包没走业务编解码流程。
- 心跳消息建议用最简裸字节，例如单字节
0x00或固定 4 字节0x00000001，绕过MessageCodec和ProcotolFrameDecoder - 发送前检查
ctx.channel().isActive()和ctx.channel().isWritable()，避免向已半关或写缓冲满的 Channel 发送 - 若必须复用业务协议，确保心跳类型字段（如
message.type == HEART_BEAT）在MessageCodec中被明确识别并跳过业务处理
真实线上容易忽略的三个细节
假死检测上线后，常因以下问题导致效果打折甚至引发雪崩：
- 超时时间不能拍脑袋定：120 秒看似安全，但若网关后接的是高延迟 IoT 设备（RTT > 800ms），且心跳间隔设为 90 秒，
READER_IDLE可能频繁误触发。建议取「典型 RTT × 3 + 心跳间隔 × 2」作为基准 -
IdleStateHandler必须加在业务解码器之后：如果放在ProcotolFrameDecoder前，它看到的是原始 TCP 流碎片，无法准确判断“是否收到完整业务包”，导致空闲计时失效 - 别忘了清理关联状态：关闭
Channel时，务必同步清除ConcurrentHashMap中的用户会话、Redis 中的 token 绑定、本地缓存里的连接元信息，否则内存泄漏比假死还难查
