内存映射适合GB级日志的只读扫描与追加写入，需分段映射、手动清理、读写分离，并注意虚拟内存泄漏、大小限制及平台差异。
Java 中用内存映射（MappedByteBuffer）处理超大日志文件，核心是避免传统 I/O 的频繁磁盘读写和 JVM 堆内存压力，适合 GB 级只读或追加场景。但它不是万能方案——不能替代随机写、不保证实时刷盘、且需注意资源释放和平台限制。
什么时候该用内存映射？
适合以下典型日志场景：
- 单次加载后反复扫描（如日志分析、关键字检索、统计聚合）
- 文件大小稳定在几 GB 到数十 GB，且机器物理内存充足（映射区域不占用堆内存，但会占虚拟地址空间和部分物理页）
- 以只读或末尾追加为主，极少中间修改（注意：随机写映射文件需配合 force() 且易引发一致性问题）
- 对延迟敏感，希望绕过内核缓冲区拷贝（如毫秒级行定位）
基本读取：按块映射 + 行解析
超大日志通常按行组织（如每行一条 JSON 或时间戳日志）。直接 map 整个几十 GB 文件可能失败（尤其 Windows 虚拟地址空间有限），推荐分段映射：
- 用
RandomAccessFile打开文件，调用getChannel().map(...) - 每次映射固定大小（如 64MB），处理完立刻
clean()（通过反射调用 Cleaner，防止内存泄漏） - 手动查找换行符（
\n或\r\n），避免String.split()触发大量小对象分配
示例关键代码片段：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
// 映射起始位置 position，长度 size MappedByteBuffer buf = channel.map(READ_ONLY, position, size); buf.load(); // 预热，触发页加载（可选） // 扫描 buf 查找 \n，切出每行字节，用 Charset.decode() 转 String // 处理完调用 clean(buf) —— 必须做！
安全追加写入：配合 FileChannel.write()
内存映射不推荐用于频繁追加（MAP_RO 不可写，MAP_RW 追加需先扩大文件并重新 map，开销大）。更稳妥做法：
- 读取分析用
MappedByteBuffer（只读映射） - 新日志追加用
FileChannel.write(ByteBuffer)，设置channel.position(fileSize)定位到末尾 - 写完调用
channel.force(true)确保落盘（尤其重要日志）
这样读写分离，兼顾性能与可靠性。
必须注意的坑
忽略这些会导致 OOM、数据丢失或程序卡死：
-
不释放映射缓冲区：JVM 不自动 GC MappedByteBuffer，必须反射调用
Cleaner.clean()，否则虚拟内存耗尽 -
映射大小超过 Integer.MAX_VALUE：32 位索引限制，需分段映射（
position + size <= Long.MAX_VALUE，但单次map()的 size ≤ 2GB） - Linux 下 tmpfs 或 ext4 挂载选项影响：如 noatime 可减少元数据更新，但 mmap 仍受 page cache 影响
- Windows 上最大映射数限制：默认约 1000 个，高并发映射需调整系统参数或复用 buffer
