NIO通道未显式关闭会导致Linux文件描述符泄漏而非JVM堆内存泄漏；表现为句柄数缓慢增长，最终引发“Too many open files”错误，可通过ls -l /proc/[pid]/fd、lsof和jstack命令组合验证，并需在代码中严格遵循谁打开谁关闭、显式判空关闭、Selector必须close等实践。
Java中NIO通道（如FileChannel、SocketChannel、ServerSocketChannel）若未显式关闭，会持续占用Linux文件描述符（FD），但不会触发JVM堆内存泄漏。这类泄漏隐蔽性强——无明显异常日志，句柄数缓慢爬升，最终在高并发或长周期运行后集中爆发“Too many open files”，导致新连接失败、文件读写阻塞甚至JVM线程卡死。
确认是否为NIO通道句柄泄漏
不依赖猜测，用系统级命令快速验证：
-
查FD总数趋势：执行
ls -l /proc/[pid]/fd | wc -l，每30秒采样一次，观察是否持续增长（尤其在无新增业务请求时仍在上升） -
聚焦NIO类型句柄：运行
lsof -p [pid] | grep -E "(anon_inode|socket|pipe|inotify)"，重点关注含socket:[、anon_inode:[eventpoll]、anon_inode:[timerfd]的行——这些正是NIO通道、Selector、Pipe等底层资源的典型标识 -
比对线程与FD关联性：用
jstack [pid] > jstack.out获取线程栈，再搜索关键词如SelectorImpl、epollWait、FileChannelImpl，看是否有大量线程长期阻塞在NIO等待或通道操作上
NIO通道泄漏的典型代码陷阱
看似规范的写法，往往就是泄漏源头：
-
Channel包装后脱离作用域：例如将
FileChannel.open(path)返回的通道传给一个静态缓存对象或异步任务，调用方已退出，但通道未被任何地方引用和关闭 -
try-with-resources未覆盖NIO资源：JDK 7+的
try-with-resources只对实现了AutoCloseable的类生效；而FileChannel虽实现该接口，但若用Channels.newInputStream(channel)包装成InputStream后再放进try块，关闭的是包装流，原始channel仍存活 -
Selector注册后未取消Key：调用
channel.register(selector, ops)后，若后续未调用key.cancel()且未关闭channel或selector，该SelectionKey会一直留在selector.keys()集合中，其关联的底层socket fd无法释放 -
异常路径绕过close逻辑：在
finally中调用channel.close()前未判空，或close()自身抛出IOException被吞掉，导致后续清理中断
安全关闭NIO通道的关键实践
不是“写了close就行”，而是确保它一定被执行、且执行有效：
立即学习“Java免费学习笔记（深入）”；
-
谁打开，谁负责关闭：避免跨方法/跨组件传递裸
Channel；如必须传递，约定接收方承担关闭责任，并在文档中标明 -
显式关闭 + 空值防护：
FileChannel channel = null; try { channel = FileChannel.open(path, StandardOpenOption.READ); // ... 业务逻辑 } catch (IOException e) { throw new RuntimeException(e); } finally { if (channel != null && channel.isOpen()) { try { channel.close(); } catch (IOException ignored) { } } } -
Selector使用后必须close：
selector.close()不仅释放自身，还会自动取消所有注册的SelectionKey并关闭其关联通道（前提是通道未被其他地方持有） -
慎用Files.newByteChannel()等便捷API：它们返回的
SeekableByteChannel需手动关闭；不要误以为“没看到new Channel”就不用关
辅助定位与预防手段
靠人工盯代码效率低，要结合工具和机制：
-
启动时开启FD跟踪：JVM加参数
-Djdk.nio.maxCachedBufferSize=0（禁用缓冲区缓存），配合-XX:+PrintGCDetails观察GC频率是否因FD耗尽引发频繁Full GC -
代码扫描：用SonarQube规则
S2095（"Resources should be closed"）或自定义Checkstyle规则，检测未关闭的Channel、Selector、AsynchronousSocketChannel等 -
压测中监控FD增长：在JMeter或Gatling压测期间，同步采集
/proc/[pid]/fd数量曲线，对比QPS与FD增量斜率，快速识别泄漏拐点
