Java NIO本身不处理丢包重传，该职责由操作系统内核TCP协议栈完成；NIO仅提供非阻塞I/O封装，需从协议配置、缓冲区管理、线程安全、流量控制及应用层兜底五方面协同保障TCP重传机制有效生效。
Java NIO 本身不处理丢包重传——这是 TCP 协议栈在操作系统内核层完成的职责，NIO 只是 Java 层对底层网络 I/O 的非阻塞封装。真正决定是否丢包、何时重传、用什么策略（如快重传、超时重传）的，是内核 TCP 实现，而非 Selector、SocketChannel 或 ByteBuffer。
但高并发下丢包问题会更显性暴露，NIO 应用需从协议层配合、缓冲区管理、线程模型和应用层兜底四个角度协同应对，才能让 TCP 的重传机制有效生效、避免误判或雪崩。
✅ 确保 TCP 连接稳定，不干扰内核重传逻辑
禁用 Nagle 算法（
TCP_NODELAY = true）
避免小包合并延迟 ACK，减少因等待而触发的“伪超时”，尤其在高频小包场景（如实时信令、心跳）中，能加快 ACK 返回，让快重传更快被触发。合理设置 TCP KeepAlive
长连接空闲时若中间设备（如 NAT、防火墙）静默断连，而应用层无感知，会导致后续发包被 RST 或直接丢弃。启用并调小 keepalive 时间（如setKeepAlive(true)+ OS 层配置），可及早发现死链，避免重传无效化。不手动关闭连接后立即复用端口（规避 TIME_WAIT 占用）
频繁建连场景下，大量TIME_WAIT会耗尽本地端口或干扰新连接的三次握手，间接加剧丢包感知。可通过SO_LINGER=0或服务端net.ipv4.tcp_tw_reuse=1（Linux）缓解。
✅ 正确使用 Buffer 和 Channel，防止应用层“假丢包”
NIO 不丢包，但写错缓冲区状态、未处理 write() 返回值、忽略 OP_WRITE 就绪，会导致数据卡在用户缓冲区，看起来像丢了，实则是没发出去：
SocketChannel.write(ByteBuffer)是非阻塞的，返回实际写出字节数（可能 → 必须检查返回值，若未写完，需保留 ByteBuffer 并注册OP_WRITE，等下次就绪再续写
→ 否则数据滞留，连接看似“卡住”或“响应丢失”使用
ByteBuffer.flip()后未clear()或compact()，下次读写易越界或跳过数据
→ 建议统一用buffer.clear()（写前）和buffer.flip()（读后），或改用 Netty 的ByteBuf（自动索引管理）多线程并发写同一 Channel：NIO Channel 不是线程安全的
→ 若多个业务线程同时调用write()，可能破坏缓冲区状态或覆盖数据 → 表现为乱序、截断、“串包”（如你知识库中提到的 WebSocket FIN/RSV 错误）
→ 解决方案：所有写操作必须串行化（如通过单线程 EventLoop、write()提交到 IO 线程队列）
✅ 主动适配 TCP 流量控制与滑动窗口
当接收端处理慢、缓冲区满，TCP 会通过 window size = 0 暂停发送（Zero Window），此时若发送端盲目重试，反而加重拥塞：
立即学习“Java免费学习笔记（深入）”；
监听
OP_WRITE不仅用于续写，也用于响应窗口恢复
→ 当内核通告窗口打开（即socket.send()可写），Selector会再次触发OP_WRITE，应用应立即尝试发送积压数据避免“发完就忘”：对关键消息（如指令、确认）可记录待确认序列号，结合
SO_SNDBUF大小预估积压能力，必要时做流控反馈（如暂停上游生产）
✅ 应用层补充：对超时/异常连接做兜底重传
TCP 保证单连接内有序可靠交付，但不保证连接永存。高并发下连接闪断、RST、SYN 超时等仍会发生：
对关键业务请求（如支付、状态同步），设计带唯一 ID 和重试语义的应用层协议
→ 服务端幂等处理，客户端在连接异常时按策略重发（如指数退避 + 最大次数）
→ 不依赖 TCP 重传，而是跨连接级保障使用健康探测（如自定义 ping/pong 帧）替代纯 TCP keepalive，更快发现半开连接
→ 一旦超时未响应，主动关闭并重建，避免持续向已失效通道写入导致“丢包幻觉”
Java NIO 是高性能网络的基石，但它不替代 TCP，也不掩盖网络本质。丢包重传靠内核，而 NIO 的价值在于——让你在高并发下不拖慢它、不干扰它、还能及时感知并配合它。
