MappedByteBuffer 不会随 FileChannel 关闭自动释放 mmap 映射，因其实质是 native 层 mmap 封装，GC 无法触发 munmap；Windows 下致文件占用，Linux/macOS 存 stale mapping 风险；需通过 Cleaner（JDK9+）或反射 sun.misc.Cleaner（JDK8）显式清理，或从设计上避免长期持有、分段映射、统一管理源头。
FileChannel.map() 生成的 MappedByteBuffer 不会随通道关闭而自动释放底层 mmap 映射，这是 Java NIO 中一个长期存在的资源管理盲区。它不提供 public close() 方法，JVM GC 也无法回收其持有的虚拟内存页和文件句柄——尤其在 Windows 上，会导致“无法删除正在被映射的文件”或重复映射时触发 Map failed 异常。
为什么 mappedByteBuffer 不释放是个真问题
根本原因在于：MappedByteBuffer 是 JVM 对操作系统 mmap 系统调用的一层轻量封装，其生命周期由 native 层 mmap 区域控制，而非 Java 堆对象引用。即使你 close() 了 RandomAccessFile 和 FileChannel，只要 MappedByteBuffer 实例还被强引用（哪怕只是局部变量未出作用域），底层映射就持续存在。GC 只能回收 ByteBuffer 对象本身，但不会调用底层 munmap()。
- Windows 下表现为文件被占用，无法删除、重命名或覆盖
- Linux/macOS 上虽允许删除文件，但映射区域仍有效（stale mapping），若原文件被其他进程截断或修改，访问越界位置会抛
IndexOutOfBoundsException - 频繁映射大文件（如循环处理日志分片）易耗尽进程虚拟地址空间，尤其 32 位 JVM 或容器内存受限环境
安全释放 mappedByteBuffer 的两种可靠方式
目前没有标准 API，但有经生产验证的可行路径：
-
推荐：用 try-with-resources + 显式 Cleaner（JDK9+）
借助java.lang.ref.Cleaner注册清理逻辑，在 MappedByteBuffer 不再强引用时触发 unmapping。需配合Unsafe或反射获取底层Cleaner实例，但 JDK9 后已开放部分支持；实际项目中建议封装为工具类，避免每次手写反射 -
兼容方案：反射调用 sun.misc.Cleaner（JDK8 及更早）
通过buffer.getClass().getDeclaredField("cleaner")获取私有 cleaner 字段，再调用其clean()方法。注意该类在 JDK14+ 被移除，仅适用于遗留系统；使用前需加 try-catch 并降级为 warn 日志
规避问题比强行释放更有效
与其依赖非标准清理机制，不如从设计上减少映射泄漏风险：
- 避免长期持有 MappedByteBuffer 实例：映射后立即读/写，用完即弃，不缓存、不跨方法传递
- 对超大文件（>2GB）强制分段映射：每次只 map ≤64MB 区域，处理完让局部变量自然失效，降低单次 unmapping 压力
- 统一用 RandomAccessFile + try-with-resources 管理源头：确保
raf.close()被调用，防止文件句柄泄漏（这比 buffer 释放更关键） - 映射前检查文件长度是否合理：防止因
size > Integer.MAX_VALUE导致 map 失败，或因 offset + size 超限抛 IOException
补充提醒：别踩这些同步与并发坑
释放只是基础，多线程或进程间共享映射时还有隐藏雷区：
- 多个线程同时对同一 MappedByteBuffer 调用
force()不是线程安全的，需外层同步 - 跨进程共享需保证：文件路径唯一、映射 offset/size 完全一致、
MapMode相同（READ_WRITE）、且双方都用 native byte order - 不要在映射期间 truncate 或 delete 文件：Linux 可能不报错但行为未定义，Windows 直接失败
