java nio中无法通过so_keepalive实现秒级心跳检测，因其是内核级tcp保活机制，默认2小时后才探测且不可配置；必须在连接完成后的socketchannel上单独设置setkeepalive(true)，仅作兜底；秒级心跳需应用层实现，推荐idlestatehandler结合ping/pong编解码。
Java NIO 中无法直接通过 Keep-Alive 实现秒级心跳检测，因为 SO_KEEPALIVE 是操作系统内核的 TCP 保活机制，不是应用层可控的心跳逻辑。它仅在连接空闲约 2 小时后才启动探测，且参数（如探测间隔、重试次数）由系统决定，Java NIO 层面只能开关，不能配置。
必须在连接建立后立即启用 SO_KEEPALIVE
Keep-Alive 开关必须作用于底层 Socket，且需在连接完成之后、数据收发之前设置，否则可能无效：
- 对
SocketChannel：调用channel.socket().setKeepAlive(true) - 服务端接受连接后，每个新
SocketChannel都要单独设置，ServerSocketChannel的选项不继承给客户端 - NIO 不支持在
configureBlocking(false)后延迟设置——必须在finishConnect()成功后立即设置
SO_KEEPALIVE 只能作为兜底，不能替代心跳
它的真实作用是：当链路物理中断或对端进程崩溃重启时，内核最终能发现并关闭失效连接。但它存在明显局限：
- 默认探测启动时间长达 7200 秒（Linux），业务无法容忍
- 中间设备（NAT、防火墙）常静默丢弃 keepalive 探测包，导致“假在线”
- 无法区分“对方进程卡死但 TCP 连接仍通”和“网络通畅”的状态
- 异常不会实时抛出，需等到下一次 read/write 操作才触发 IOException
真正可用的心跳必须靠应用层实现
在 NIO 场景中，推荐结合 IdleStateHandler + 自定义心跳编解码器：
- 在 ChannelPipeline 中添加
new IdleStateHandler(30, 30, 0, TimeUnit.SECONDS)，30 秒无读写即触发事件 - 重写
userEventTriggered()方法：收到READER_IDLE时发送 PING；收到 PONG 响应则重置状态 - 配合
writeAndFlush()异步发送心跳，避免阻塞 EventLoop - 心跳消息建议用轻量协议（如纯文本 "PING"/"PONG" 或短二进制标记），减少序列化开销
生产环境必须组合使用
可靠长连接 = SO_KEEPALIVE（防系统级连接滞留） + 应用层心跳（秒级感知） + 读写超时（socket.setSoTimeout() 不适用 NIO，改用 IdleStateHandler 或 Future.await() 超时控制）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
