MappedByteBuffer在GB级日志写入中易因映射失败、脏页刷盘失控和GC压力导致性能反降；应改用分段映射+RingBuffer或FileChannel+DirectBuffer方案。
零拷贝 ≠ 无代价，MappedByteBuffer 在 GB 级日志场景下容易因内存映射失败、脏页刷盘失控或 GC 压力反拖慢性能——直接用它做高频写入反而比普通 FileChannel 更慢。
为什么 MappedByteBuffer 写 GB 日志常掉坑里
Java 的 MappedByteBuffer 底层调用 mmap()，把文件区域映射进用户态虚拟地址空间，绕过内核缓冲区拷贝。听起来很美，但日志写入不是只读场景：
- 每次
put()修改映射内容，会触发缺页中断+脏页标记，OS 后台线程（pdflush或writeback）异步刷盘——你无法控制刷盘时机和节奏 - GB 文件全量映射（如
channel.map(READ_WRITE, 0, file.length())）极易触发OutOfMemoryError: Map failed，因为 JVM 虽不计入堆内存，但受限于进程虚拟地址空间（32 位机器尤其致命，64 位也受/proc/sys/vm/max_map_count限制） -
MappedByteBuffer不受 JVM GC 管理，但其 backing memory 的释放依赖Cleaner，而 Cleaner 执行时机不可控；频繁创建/丢弃映射易堆积 dirty pages，拖垮系统 I/O - 日志通常是追加写（append），但
MappedByteBuffer固定大小，扩容需重新映射——这会断开旧引用，且无法原子切换
真正能落地的分段映射 + RingBuffer 模式
把一个大日志文件切分成多个固定大小（如 16MB）的逻辑块，每个块按需映射、写满即换、显式清理。这不是“避免映射”，而是让映射行为可控：
- 使用
RandomAccessFile.getChannel().map()映射当前活跃块，大小设为16 * 1024 * 1024，避免单次映射过大 - 维护一个
currentOffset记录当前写位置，每次写前检查是否超出当前映射范围；超了就force()刷脏页，unmap()旧 buffer，再映射下一块 -
unmap()必须手动触发：JDK 9+ 可用java.nio.channels.FileChannel.MapMode配合Cleaner，JDK 8 只能反射调用sun.misc.Cleaner（示例中必须加--add-opens java.base/sun.misc=ALL-UNNAMED） - 写入时用
buffer.put(byte[])批量写，避免单字节put()——后者会反复触发边界检查和 volatile 写，性能断崖下跌
// JDK 8 反射 unmap 示例（仅作示意，生产环境建议升级 JDK）
private static void unmap(MappedByteBuffer buffer) {
try {
Method cleaner = buffer.getClass().getMethod("cleaner");
cleaner.setAccessible(true);
Object cleanObj = cleaner.invoke(buffer);
Method cleanMethod = cleanObj.getClass().getMethod("clean");
cleanMethod.invoke(cleanObj);
} catch (Exception e) {
// ignore
}
}
比 MappedByteBuffer 更稳的日志写法：FileChannel + DirectBuffer
对大多数 GB 级日志（尤其是高吞吐、低延迟要求），直接用 FileChannel.write(ByteBuffer) 配合堆外 ByteBuffer.allocateDirect() 是更优解：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
-
allocateDirect()分配的 buffer 由 OS 管理，JVM GC 不扫描，生命周期明确；配合FileChannel.write()，内核可自动合并小 write 为大 I/O，实际也规避了多次 copy - 无需管理虚拟地址碎片，无
Map failed风险；通过调整 buffer 大小（如 128KB）平衡内存占用与系统调用次数 - 可配合
FileChannel.force(false)控制元数据刷盘频率，或force(true)强制刷数据+元数据（适用于 crash-safe 场景） - 若需日志滚动，直接 close 当前 channel、open 新文件即可，语义清晰，无映射残留问题
最后提醒两个真实线上陷阱
一是 MappedByteBuffer.force() 并不等价于 fsync() ——它只保证映射页写入 page cache，不保证落盘；真要确保不丢日志，仍需 FileChannel.force(true) 或外部 fdatasync() 调用。
二是 Linux 下 mmap() 映射的文件被 truncate 或删除时，映射依然有效，但后续写入可能触发 SIGBUS（JVM 中表现为 java.lang.InternalError）；日志归档脚本若暴力 rm 正在映射的文件，服务大概率崩。
