Java NIO用MappedByteBuffer处理超大文件的核心是操作系统内存映射机制，需分段映射（如64MB）、合理选模式（READ_ONLY/READ_WRITE/PRIVATE）、注意缓冲区状态与字节序，并手动清理资源。
Java NIO 使用 MappedByteBuffer 处理超大文件，核心不是“把整个文件塞进内存”，而是用操作系统级的内存映射机制，按需加载、随机访问、避免拷贝。关键在合理分段、控制访问方式、及时释放资源。
分段映射，别一次性 map 整个几十 GB 文件
直接 channel.map(..., 0, file.size()) 映射一个 20GB 文件，不会立刻卡死，但第一次遍历或强读（比如 for 循环调用 get(i)）会触发大量缺页中断，瞬间拉满磁盘 IO，表现就是“一访问就卡住”。这不是 Java 慢，是操作系统在按需加载页面。
- 按固定大小切片，例如每次映射 64MB 或 128MB：用
channel.map(mode, offset, size)控制起始位置和长度 - 读完当前段后，显式放弃引用（置 null），再 map 下一段；避免多个 MappedByteBuffer 长期堆积
- 对顺序读场景，分段映射 + 批量
buffer.get(byteArray)比全量映射 + 单字节 get() 快得多也稳得多
选对模式，明确读写语义
FileChannel.MapMode 决定了数据流向和可见性，不能只看名字乱配：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
READ_ONLY：适合日志分析、配置读取等只读场景；尝试写会抛
ReadOnlyBufferException -
READ_WRITE：修改 buffer 内容会同步回文件，但不保证立即落盘；需调用
buffer.force()强刷（尤其重要数据） - PRIVATE：写操作只影响当前进程的副本，不回写文件，适合做临时解析、解密缓存等
- 多进程共享同一文件区域通信时，必须统一用
READ_WRITE，且所有进程打开的是**同一个真实磁盘文件路径**
小心缓冲区状态和字节序
MappedByteBuffer 是 ByteBuffer 的子类，继承了 position/limit 等状态，但容易被忽略：
立即学习“Java免费学习笔记（深入）”；
- 不要反复调用
map()创建新 buffer 却不清理旧实例；JVM GC 不自动释放底层 mmap，长期运行易导致OutOfMemoryError: Map failed - 写结构化数据（如 int、long 字段）前，先
buffer.position(offset).putInt(value)，避免因 position 漂移导致后续读错位 - 涉及跨平台或进程间共享数据，务必调用
buffer.order(ByteOrder.nativeOrder())统一大小端，否则解析结果错乱 - 调用
load()可预热页面（强制加载到物理内存），但仅在真正需要全量驻留时使用，否则浪费资源
资源清理不能靠 GC，得手动干预
MappedByteBuffer 的底层是 OS 的 mmap 区域，JVM 不负责回收。Java 9+ 提供了 Cleaner 机制，虽属非公开 API，但在生产中常需借助：
- 映射后保存 reference，业务结束时尝试反射调用
Cleaner.clean()（有兼容风险，建议封装成工具方法） - 更稳妥做法：复用少量固定大小的 MappedByteBuffer 实例，配合分段逻辑循环使用，减少频繁映射/释放
- 始终关闭上游资源：
FileChannel.close()和RandomAccessFile.close()必须成对调用，否则文件句柄泄漏
