java nio常见报错分四类：一、closedchannelexception因通道关闭后误操作，需检查生命周期与isopen()；二、bufferunderflow/overflowexception源于bytebuffer状态混乱，应规范flip/clear/compact调用；三、selector空轮询或阻塞需用超时+重建规避jdk bug；四、ioexception需按网络或文件上下文分类处理。
Java NIO 网络编程常见报错，核心集中在三类：通道状态异常、缓冲区操作错误、Selector 事件处理失当。排查不是靠猜，而是顺着“通道生命周期—缓冲区状态—事件流转”这条主线，逐层定位。
一、ClosedChannelException：通道已关闭却还在用
这是最典型的“时序错误”。不是代码写错了，而是逻辑没管住资源生命周期。
-
重点检查点：所有调用
channel.read()、channel.write()、key.cancel()的地方，确认该 channel 是否已被显式关闭（close()），或是否在其他线程中被提前关闭 -
推荐做法：使用 try-with-resources 包裹可关闭资源；对 channel 操作前加判空和 isOpen() 检查：
if (channel != null && channel.isOpen()) { ... } - 高发场景：连接断开后未及时取消 SelectionKey，后续 selector 仍轮询到该 key 并尝试 read/write；多线程共享 channel 且无同步保护
二、BufferUnderflowException / BufferOverflowException：ByteBuffer 状态混乱
本质是 position、limit、capacity 三者关系失控，90% 源于 flip()/clear()/compact() 用错时机。
- 读取报 Underflow：说明想 get() 但 position ≥ limit。典型是忘记 flip() 就直接 read()，或部分读取后又误调 flip() 把 limit 缩小了
- 写入报 Overflow：说明 put() 时 position ≥ limit。常见于 clear() 后未检查剩余空间就连续写入，或 compact() 后未 flip 就 write 到 Channel
-
快速验证法：在关键操作前后打印 buffer 状态：
System.out.println(buffer + " | pos:" + buffer.position() + " lim:" + buffer.limit())
三、Selector 空轮询或 select() 长时间阻塞
表现为 CPU 占用飙升或连接响应迟钝，根源常在 JDK epoll 实现的底层 Bug 或事件注册不完整。
- 先确认是否空轮询：在 select 循环中统计返回 0 的次数，连续数百次即大概率触发 JDK-6403933 Bug
-
规避手段：设置超时（
selector.select(1000)），配合空轮询计数器，达到阈值后重建 Selector（注意重新注册所有 Channel） - 更优解：生产环境直接采用 Netty —— 它通过自研 EpollEventLoop 绕过 JDK 原生 Selector 的 epoll 封装缺陷，从根上解决空轮询
四、IOException（含 NoSuchFileException、Connection reset）
NIO 中的 IOException 多为底层系统调用失败的透出，需结合上下文判断是网络问题还是本地资源问题。
- SocketChannel 场景：read() 返回 -1 表示对端正常关闭；抛 IOException 且 message 含 “Connection reset” 说明对方强制断连；含 “Broken pipe” 是本端写入时连接已断
-
文件路径类异常：如
NoSuchFileException，优先检查 Path 是否为绝对路径、父目录是否存在、权限是否足够，不要依赖相对路径的当前工作目录 - 统一处理建议：对 IOException 做分类捕获，网络类异常记录 warn 日志并关闭对应 channel；文件类异常先校验路径有效性再重试或告警
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
