SocketChannel无内置心跳机制，需应用层实现：客户端每15秒发4字节心跳包，服务端立即ACK；通过lastReadTime/lastWriteTime时间戳检测超时，配合ScheduledExecutorService调度与Selector事件循环保障可靠性。
Java原生套接字通道（SocketChannel）本身不内置心跳机制，需由应用层主动设计并维护。核心思路是：在连接建立后，客户端与服务端约定周期性互发轻量心跳包（如固定字节或简单JSON），同时配合读写超时、空闲检测与异常捕获，确保连接有效性。
心跳协议设计与数据格式
避免使用复杂序列化，推荐二进制或紧凑文本格式：
- 客户端每15秒向服务端发送4字节：0x01 0x02 0x03 0x04（自定义心跳标识）
- 服务端收到后立即回发相同4字节作为ACK，不解析内容，仅验证长度和模式
- 禁用含时间戳或随机数的协议——会增加解析开销且无实际必要
非阻塞通道下的心跳触发与检测
基于Selector轮询时，不能依赖单一线程阻塞等待；需将心跳纳入事件驱动循环：
- 用
ScheduledExecutorService单独调度心跳发送任务（如每15秒执行一次channel.write(ByteBuffer.wrap(HEARTBEAT_BYTES))） - 记录每次成功写入的时间戳（
lastWriteTime），在OP_READ就绪时更新lastReadTime - 在每次
select()返回前，检查System.currentTimeMillis() - lastReadTime > 30_000，超时则主动关闭通道
读写超时与连接状态兜底
操作系统TCP栈不保证及时通知断连，必须叠加多层检测：
立即学习“Java免费学习笔记（深入）”；
- 设置
socket.setSoTimeout(20_000)（仅对阻塞I/O有效）——若用非阻塞模式，则此设置无效，需靠上层逻辑判断 - 每次
write()后检查返回值：若为0，说明内核发送缓冲区满，不是错误，但需关注后续是否恢复；若抛IOException（如Connection reset / Broken pipe），立即清理连接 - 对端静默断连（如直接拔网线）时，
read()可能长期不就绪，此时依赖前述lastReadTime超时判定
服务端心跳响应与连接管理
服务端不应被动等待心跳包，而应统一处理所有入站数据，并快速响应：
- 在
OP_READ分支中，先read()到ByteBuffer，若数据长度为4且匹配心跳特征，立即write()回相同字节，不入业务队列 - 使用
ConcurrentHashMap<SocketChannel, Long>维护每个连接的lastReadTime，读写操作加锁或用原子更新 - 定期（如每10秒）扫描该Map，剔除超时连接并调用
channel.close()和key.cancel()
不复杂但容易忽略的是：心跳不是“发了就行”，关键在两端严格同步检测逻辑，并以时间戳为唯一可信依据。只要读写时间窗口可控、超时阈值留有余量（建议心跳间隔 ≤ 超时阈值的1/2），就能稳定识别真实断连。
