当JVM中文件描述符耗尽触达ulimit -n软限制时，NIO操作底层因EMFILE错误映射为java.io.IOException: Too many open files，非自愈型异常；JVM不监控FD总量、不自动释放或提限，需系统层调优、应用层显式close及泄漏排查协同解决。
当 JVM 中文件描述符（FD）耗尽、触达 ulimit -n 的软限制时，NIO 操作不会直接抛出特定“FD 耗尽异常”，而是通过底层系统调用失败，最终映射为标准的 Java I/O 异常——最常见的是 java.io.IOException: Too many open files。这不是 JVM 主动检测并抛出的“自愈型”异常，而是一个明确的失败信号，**不带自愈能力**。
底层异常的触发路径
Java NIO（如 SocketChannel、FileChannel、AsynchronousSocketChannel）在底层依赖系统调用：socket()、open()、accept()、epoll_ctl() 等。一旦进程已打开的 FD 数达到 ulimit -n（软限制），内核会拒绝新分配 FD，返回错误码 EMFILE（每个进程打开文件数超限）。JVM 的 NIO 实现（如 sun.nio.ch 包）捕获该错误后，统一包装为：
-
java.io.IOException: Too many open files（最常见，如ServerSocketChannel.accept()失败） -
java.nio.channels.ClosedChannelException（部分场景下因通道初始化失败间接导致） -
java.nio.channels.AsynchronousCloseException（仅在多线程并发关闭通道时触发，与 FD 耗尽无关，属正常竞态，非资源不足所致）
为什么没有“自愈”机制
JVM 本身不监控或管理操作系统的 FD 总量，也不具备自动释放闲置 FD 的能力。所谓“自愈”是误解——异常发生后：
- 不会自动回收已泄漏的 FD（如未 close 的
SocketChannel或FileInputStream） - 不会动态提升 ulimit 限制（需 root 权限且影响整个进程生命周期）
- 不会主动触发 GC 来释放与 FD 关联的对象（FD 本身由内核持有，GC 只能回收 Java 对象，不保证
finalize()或Cleaner立即执行）
真正有效的应对方式
必须从系统层、JVM 层和应用层协同干预：
- 确认并提高软硬限制：运行
ulimit -Sn和ulimit -Hn查看当前值；生产环境建议设为65536（软/硬一致），通过/etc/security/limits.conf或 systemd 的LimitNOFILE=持久化 - 启用 NIO 的资源自动清理：确保使用
try-with-resources或显式channel.close()；对AsynchronousSocketChannel，注意CompletionHandler中异常分支也要 close - 排查 FD 泄漏：用
lsof -p <pid>统计 FD 类型分布；重点关注socket、anon_inode（如 epoll）、pipe是否持续增长 - 避免阻塞式长连接堆积：在 NIO 服务端设置合理的
SO_TIMEOUT或connectionTimeout，及时关闭空闲连接
补充说明：GC 与 Cleaner 的作用边界
Java 9+ 中，NIO 的 direct buffer 和部分 channel 使用 Cleaner 注册释放逻辑，但该机制：
- 只在对象被 GC 回收后才尝试清理，不保证及时性
- 无法处理未被 GC 的活跃对象（如连接池中长期复用但未正确归还的 channel）
- 不能替代显式 close，更不能缓解 ulimit 触顶后的即时失败
