直接映射几十GB文件易卡死或抛OutOfMemoryError，应分段映射（如每块64MB），控制单次映射大小（16MB–128MB），避免全量映射；每个写线程需独立MappedByteBuffer实例，禁跨线程共享；保持零拷贝需避免get(byte[])等堆复制操作；每次写后需force()刷盘，复用前clear()重置位置。
直接用 MappedByteBuffer 映射几十 GB 的文件，大概率会卡死或抛 OutOfMemoryError: Map failed。这不是 Java 问题，而是操作系统对单进程 mmap 区域数量有限制（Linux 默认 vm.max_map_count=65536），且映射本身消耗虚拟地址空间——尤其在频繁追加日志的场景下，一次性全量映射既没必要，也极易触发内核资源瓶颈。
分段映射是关键
GB 级日志通常是持续追加的，不需要、也不该一次映射整个文件。核心是控制“映多少、何时映、怎么换”：
- 单次映射大小建议设为 16MB–128MB，具体根据写入频率和系统
vm.max_map_count调整； - 避免传
file.length()或Integer.MAX_VALUE给map()，这等于向内核申请过大虚拟地址段； - 把文件逻辑切分为固定块（如每块 64MB），只映射当前活跃块；
- 写满当前 buffer 后，先调用
force()刷盘，再创建新 buffer 并更新引用，旧 buffer 不再强引用，交由 GC 自然回收。
线程安全与模式选择
MappedByteBuffer 实例不是线程安全的，多线程并发写同一实例会导致数据错乱：
- 每个写线程应持有独立的
MappedByteBuffer引用（例如配合 ThreadLocal 或按块分配）； - 即使只读也要慎用
READ_ONLY，后续若需追加内容，必须用READ_WRITE模式映射； - 不要在多个线程间共享同一个 buffer 实例，也不要跨线程复用未清理的 buffer。
保持零拷贝路径不被破坏
所谓“零拷贝”是指数据不经过 JVM 堆中转，但业务代码很容易无意退出该路径：
立即学习“Java免费学习笔记（深入）”；
- 避免调用
buffer.get(byte[])或StandardCharsets.UTF_8.decode(buffer)，这会复制数据到堆内存； - 逐行解析日志时，用
buffer.position()和buffer.limit()定位，配合buffer.get(i)单字节扫描换行符； - 需要字符视图时，优先用
buffer.asCharBuffer()（注意字节序），而非 decode 构造新字符串。
资源与状态管理不能省
映射后的 buffer 需主动维护状态，否则脏页滞留或位置错乱会引发数据丢失或越界：
- 每次写操作后，若需立即持久化，必须显式调用
buffer.force()； - 复用前务必调用
buffer.clear()重置 position/limit，否则下次写入可能覆盖错误位置； - Java 9+ 可通过反射调用 Cleaner 释放底层映射（非必需），但更稳妥的做法是确保旧 buffer 不再被引用，依赖 GC 回收。
