java nio性能优化核心是提升selector效率、减少channel数据拷贝、规范buffer状态管理、严格管控连接生命周期。具体包括：事件处理轻量及时、善用零拷贝、严格flip/clear/compact、显式释放资源。
Java NIO 优化网络 IO 的核心性能指标，关键不在“堆参数”或“加机器”，而在于**让 Selector 更高效地工作、让 Channel 数据搬运更少拷贝、让 Buffer 使用更贴合内核机制**。下面从四个实操性强的方向展开。
Selector 事件处理要轻量且及时
Selector 是 NIO 的调度中枢，它的效率直接决定单线程能扛多少连接。常见瓶颈不是连接数多，而是某个 key 的处理逻辑太重（比如在 OP_READ 中做 JSON 解析+DB 查询）。
- OP_ACCEPT、OP_READ、OP_WRITE 的回调里只做最必要的事：读取就绪数据到 Buffer、记录写状态、注册新连接；业务解码/响应生成必须交给业务线程池
- 每次 select() 返回后，务必调用 iterator.remove()，否则同一 key 会重复触发，导致 CPU 空转甚至事件丢失
- 避免在 selector 线程中执行阻塞操作（如 System.in.read()、sleep、同步日志），否则整个事件循环卡住
Channel 传输优先用零拷贝能力
NIO 的吞吐优势一大半来自减少用户态与内核态之间的数据拷贝。普通 read()/write() 仍需两次拷贝（内核→用户→内核），而某些 Channel 方法可绕过用户空间。
- 文件传输用 FileChannel.transferTo()/transferFrom()：数据在内核空间直接搬运，不进 JVM 堆，适合大文件分发、日志归档
- 网络传输中，若使用 SocketChannel.write(ByteBuffer) 且 ByteBuffer 是 direct buffer（allocateDirect），可配合 TCP 的 sendfile 或 splice 提升效率
- 避免频繁创建小 Buffer，复用 ByteBufferPool（如 Netty 的 PooledByteBufAllocator）减少 GC 压力
Buffer 状态管理必须严格遵循读写模式切换
Buffer 不是普通数组，position/limit/capacity 的错位会导致数据读不到、写不进、甚至静默丢包。
- 写入后调用 flip() 才能正确进入读模式（limit=position, position=0）；读完后若需复用，调用 clear()（重置 position=0, limit=capacity）或 compact()（把未读数据移到开头，适合部分读场景）
- 网络读场景中，不能假设一次 read() 就填满 buffer——必须检查返回值（实际读取字节数），为 -1（连接关闭）、0（非阻塞下暂无数据）、正数（有数据）分别处理
- 对高吞吐服务，建议 buffer 容量与典型报文大小匹配（如 HTTP 头部常用 8KB，消息体另设接收缓冲区），避免过小导致多次 read、过大浪费内存
连接与资源生命周期必须显式管控
NIO 是非阻塞模型，但不等于“不用管资源”。连接泄漏、buffer 未释放、channel 未 close，都会在高并发下快速耗尽 fd 或内存。
- 每个 SocketChannel 注册前必须 configureBlocking(false)；accept 后的 client channel 要设置合理的 SO_RCVBUF/SO_SNDBUF（如 64KB）并开启 TCP_NODELAY
- 异常断连时，不仅要在 catch 中 close channel，还要从 selector 中取消对应 key：key.cancel(); channel.close();
- 避免在 finally 块里无条件调用 buffer.clear() —— 若 buffer 正被其他线程引用（如异步写），会引发数据错乱；应由使用者负责 buffer 归还逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
