根本原因是MappedByteBuffer映射的native内存未释放，操作系统仍持有文件句柄；即使FileChannel等流已关闭，Cleaner依赖不可控的GC触发unmap，导致delete()失败、lsof显示anon_inode条目、容器中RES异常上涨。

Java 中使用 MappedByteBuffer 后文件无法删除，根本原因不是“没关流”，而是映射的 native 内存未释放，操作系统仍持有该文件句柄——哪怕所有 Java 流（FileChannel、FileInputStream）都已关闭，文件仍被锁定。

为什么文件删不掉？

内存映射由内核管理，JVM 仅维护一个 Java 对象（MappedByteBuffer）作为入口。该对象背后关联着一个 Cleaner，靠 GC 触发清理逻辑（调用底层 unmap）。但 GC 不及时、不可控，导致：

• 文件句柄持续占用，f.delete() 返回 false；
• lsof -p 显示大量 anon_inode:[memfd:] 或 memfd: 条目；
• 容器环境下（如 Kubernetes），memory.limit_in_bytes 不统计 native 内存，RES 持续上涨却查不到堆泄漏。

反射调用 Cleaner 是主流解法（JDK 8–17）

必须主动触发清理，不能等 GC。核心是获取并运行其关联的 Cleaner：

• 通过 buffer.getClass().getMethod("cleaner").invoke(buffer) 获取 Cleaner 实例；
• 再调用 cleaner.clean() 执行释放；
• JDK 9+ 需添加启动参数：--add-opens java.base/jdk.internal.ref=ALL-UNNAMED，否则反射失败；
• 注意：JDK 21+ 模块限制更严，此方式可能失效，需评估升级影响。

更稳妥的工程实践

避免在高频或长生命周期场景中反复创建/丢弃 MappedByteBuffer：

• 复用同一实例，尤其对固定配置文件、只读资源等；
• 批处理任务中，用 try-with-resources 包一层自定义的 AutoCloseable 封装类，在 close() 中完成反射清理；
• 映射前预估大小，单次映射不超过 2GB（Integer.MAX_VALUE 是安全上限）；超大文件务必分片映射，每次映射后立即清理；
• 禁用 System.gc() —— 它既不保证触发 Cleaner，又干扰正常 GC 节奏。

什么情况下建议绕开 MappedByteBuffer？

当出现以下任一条件时，应优先考虑传统 FileChannel.transferTo/transferFrom 或带缓冲的 InputStream/OutputStream：

• 文件稳定大于 1GB，且部署在内存受限容器中；
• 需要写入并保证数据落盘（force() 有延迟，且不解决句柄问题）；
• 运行环境无法添加 JVM 参数（如某些 PaaS 平台）；
• 要求文件可随时被外部进程删除或替换（如热更新配置）。