Java NIO通过单线程多路复用预防资源耗尽，但不当实践如缓冲区泄漏、Selector事件未清理、连接未限流等仍会导致fd耗尽、DirectMemory OOM或CPU空转。
Java NIO 本身不直接“处理”资源耗尽，而是通过设计机制**预防**高并发下的资源耗尽——核心是避免 BIO 的“一连接一线程”模式，改用单线程多路复用模型。真正导致资源耗尽的，往往是使用 NIO 时的不当实践，比如缓冲区泄漏、Selector 事件未清理、连接未限流等。
控制连接数：防止句柄和内存被撑爆
操作系统对每个进程能打开的文件描述符（包括 Socket）数量有限制（如 Linux 默认 1024）。NIO 虽不为每个连接开线程，但每个 Channel 仍占用一个 fd。若不限制接入连接数，fd 耗尽后新连接将被拒绝（抛 IOException: Too many open files）。
- 在 ServerSocketChannel.accept() 前检查当前活跃连接数，超过阈值直接 close() 新连接或返回 503
- 配合系统调优：增大 ulimit -n，并在 JVM 启动参数中设置 -XX:MaxDirectMemorySize 防止堆外内存溢出（ByteBuffer.allocateDirect 分配的是堆外内存）
- 使用连接空闲超时（readTimeout/writeTimeout）及时关闭长期无数据的连接，释放 fd 和 Buffer
合理管理 Buffer：避免堆外内存泄漏
NIO 大量使用 ByteBuffer，尤其是 allocateDirect 创建的直接内存。这类内存不受 GC 直接管理，若未显式清理或反复创建未复用，极易引发 Direct buffer memory OOM。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 优先复用 ByteBuffer：用对象池（如 Netty 的 PooledByteBufAllocator）管理 direct buffer，避免频繁分配/释放
- 避免在每次 read() 后 new 一个新 buffer；固定大小 buffer 可 clear() 后重复使用
- 监控 DirectMemory 使用：通过 JVM 参数 -XX:+PrintGCDetails 或 JMX 查看 java.nio.Bits.usedDirectMemory
正确使用 Selector：防止事件积压与 CPU 空转
Selector 是 NIO 的调度中枢，但用错会导致 CPU 占用飙升或事件丢失：
立即学习“Java免费学习笔记（深入）”；
- 每次处理完 selectedKeys() 后必须调用 keyIterator.remove()，否则该 key 会持续出现在下一轮 selectedKeys 中，造成无限循环
- 不要在 selector.select() 后长时间阻塞业务逻辑（如同步 DB 查询），否则整个 I/O 线程卡住，所有连接响应停滞；应把耗时操作提交到业务线程池
- 避免 select(timeout) 设置过小（如 1ms），导致频繁轮询、CPU 空转；推荐用无参 select() 或合理 timeout（如 100–1000ms）
连接生命周期管理：及时释放资源
Channel、SelectionKey、Buffer 都需主动关闭或取消，不能依赖 GC。
- 连接断开时，调用 key.cancel() + channel.close()，并显式置空相关引用
- 读写异常时（如 IOException），立即关闭 channel 并清理对应 buffer，防止半开连接堆积
- 对粘包/拆包场景，避免因解析失败导致 buffer 一直持有无法释放；可设置最大帧长度，超长直接丢弃并断连
