根本原因是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 <pid></pid>显示大量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 平台）；
- 要求文件可随时被外部进程删除或替换（如热更新配置）。
