ReadTimeoutHandler触发后连接不会自动断开，仅抛出ReadTimeoutException；必须在userEventTriggered中手动调用ctx.close()释放资源，否则连接将处于半开状态。
ReadTimeoutHandler 触发后连接是不是就断了？
不是自动断开，ReadTimeoutHandler 默认只触发一次 userEventTriggered 事件，抛出 ReadTimeoutException，但不会主动关闭 Channel。是否断连得看你的业务逻辑怎么处理这个异常。
常见错误现象：加了 ReadTimeoutHandler 却发现超时后请求还在跑、资源没释放、下游还在等响应——就是因为没在 userEventTriggered 里调用 ctx.close() 或 ctx.channel().close()。
- 必须手动关闭 Channel，否则连接会卡在半开状态，尤其在长连接场景下容易堆积
- 如果用了
SimpleChannelInboundHandler，记得在userEventTriggered中调用ctx.fireUserEventTriggered(evt)向后传递，否则后续 handler 收不到 - 超时异常是
ReadTimeoutException，不是IOException，别用 catchException模糊兜底
定时任务取消不掉？可能是 Channel 已经 inactive
Netty 的 ReadTimeoutHandler 内部靠 ScheduledFuture 实现超时检测，但它依赖 Channel 的 EventLoop 线程调度。一旦 Channel 已关闭（isActive() == false），再尝试 cancel 这个 future 往往无效或静默失败。
使用场景：你可能在 channelInactive 回调里想清理所有 pending timeout task，却发现 future.cancel(true) 返回 false。
- cancel 前先检查
future.isDone() || future.isCancelled()，避免重复调用 - 更稳妥的做法是在
channelActive时把ScheduledFuture存到Channel.attr()，在channelInactive里取出来 cancel —— 但前提是 future 还没触发 - 注意：Netty 4.1+ 中
ReadTimeoutHandler不再暴露内部 future，如需精细控制，建议自定义 handler 替代
为什么设置了 5 秒超时，实际却等了 10 秒才触发？
超时时间从「上一次读操作完成」开始计算，不是从连接建立或请求到达算起。如果客户端分多次发包（比如大文件上传、流式 JSON），而中间两次读之间间隔超过设定值，就会误判为超时。
参数差异：ReadTimeoutHandler 构造函数只接受一个 timeoutSeconds，它监控的是「两次 channelReadComplete 的间隔」，不是单次读的耗时。
- HTTP 场景下，如果用
HttpObjectAggregator聚合完整请求，超时判断点其实是聚合完成那一刻，不是首字节到达时 - 对 WebSocket 或自定义协议，若业务层自己 hold 住 ByteBuf 不调用
ctx.fireChannelRead()，也会导致超时计时器一直不重置 - 调试时可加日志打点
channelRead和channelReadComplete，确认实际读完成节奏
不用 ReadTimeoutHandler，自己用 EventLoop.schedule 怎么写才安全？
可以，但要注意线程安全和生命周期绑定。直接 new 一个 Runnable 丢给 eventLoop().schedule() 是最常见写法，但容易漏掉 Channel 关闭时的清理。
性能影响：频繁 schedule/cancel 小时间间隔任务（如 sub-second）会增加 EventLoop 负担；建议超时粒度 ≥ 100ms。
- 务必用
Channel.attr()绑定 future，避免闭包引用导致内存泄漏 - cancel 时加 try-catch，因为 future 可能已被执行或已取消，
cancel(true)在某些老版本 Netty 会抛RejectedExecutionException - 示例关键片段：
ChannelHandlerContext ctx = ...; ScheduledFuture<?> timeoutFuture = ctx.executor().schedule(() -> { if (ctx.channel().isActive()) { ctx.channel().close(); } }, 5, TimeUnit.SECONDS); ctx.channel().attr(TIMEOUT_KEY).set(timeoutFuture);
