核心问题是堆外内存和文件描述符失控增长；directbuffer依赖cleaner异步释放易滞后，channel/selector未显式close会导致句柄泄漏，须结合池化复用、显式释放、参数约束与nmt监控综合治理。
Java NIO 中网络 IO 引发的内存泄漏，核心问题不在堆内存，而在堆外内存（DirectBuffer）和文件描述符（file descriptor）的失控增长。不及时释放会导致 OutOfMemoryError: Direct buffer memory、Too many open files，甚至服务假死。
重点盯住 DirectByteBuffer 的生命周期
NIO 网络通信（如 SocketChannel、ServerSocketChannel）默认使用 ByteBuffer.allocateDirect() 分配堆外内存作缓冲区。这类内存不受 GC 直接管理，必须靠 Cleaner 或显式释放：
- Netty 等框架内部通常自动调用
buffer.release()（基于引用计数），但前提是业务代码不能“漏掉”释放点，比如在异常分支、超时回调、连接异常断开时忘记 release - 若使用原生 NIO（未封装），每次
allocateDirect()后，务必在数据读写完成、连接关闭后调用buffer.clear()或直接丢弃（让 Cleaner 回收）；但不能依赖 Cleaner 及时触发——GC 不确定，高负载下 Cleaner 可能严重滞后 - 避免重复分配：不要在每次 read/write 循环中都 new DirectBuffer；应复用
PooledByteBufAllocator（Netty）或自建 ByteBuffer 缓冲池
别忽视 Channel 和 Selector 的资源泄漏
每个打开的 SocketChannel、ServerSocketChannel 都占用一个操作系统文件描述符；Selector 本身也持有一些本地资源：
- Channel 必须显式调用
close()，且应在finally块或 try-with-resources 中执行（注意：Channel 实现了AutoCloseable） - Selector 也要 close —— 特别是多路复用场景中，一个 Selector 管理数百连接，若未 close，其底层 epoll/kqueue 句柄会持续泄漏
- 注册到 Selector 的 SelectionKey，一旦 Channel 关闭，对应 Key 应及时取消（
key.cancel()），否则可能阻塞 Selector 的 cleanup 逻辑
配置与监控双管齐下
光靠编码规范不够，需通过 JVM 参数和运行时指标主动约束和感知：
- 设置堆外内存上限：
-XX:MaxDirectMemorySize=512m，防止无节制分配导致 OOM - 开启本地内存追踪：
-XX:NativeMemoryTracking=detail，用jcmd <pid> VM.native_memory summary</pid>定期查看 direct memory 使用趋势 - 监控文件描述符数：
lsof -p <pid> | wc -l</pid>或 /proc//fd/ 下数量，超过系统限制（如 65535）即预警 - Netty 用户可启用
-Dio.netty.leakDetectionLevel=advanced，捕获未 release 的 ByteBuf 调用栈
规避常见伪安全写法
以下做法看似合理，实则埋雷：
- 只在正常流程 close Channel，但未覆盖异常路径（如 OP_READ 中抛出 IOException 后直接 return，忘了 close）
- 把 ByteBuf 传给异步线程或缓存后，在原始线程里就 release —— 导致后续读写访问已释放内存（出现
IllegalReferenceCountException或静默错乱） - 用 try-with-resources 包裹 Channel，但 Channel 内部持有的 ByteBuf 是手动分配的，未纳入资源管理范围
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
