java应用不直接管理page cache，而是通过复用filechannel、顺序读、批量写、避免o_direct等方式借力操作系统内核的page cache机制提升i/o性能；mappedbytebuffer则提供直接映射接口，实现零拷贝随机访问。
让读操作命中 Page Cache
当 Java 调用 FileChannel.read() 或 InputStream.read() 读取文件时，只要文件内容已在内存中，Linux 就会直接从 Page Cache 返回数据，跳过磁盘访问。
- 避免频繁打开/关闭文件：重复 open/close 会破坏内核对文件访问模式的预判，影响 read-ahead（预读）效果；保持
FileChannel复用更利于 Page Cache 持久驻留 - 顺序读优于随机读：Page Cache 的预读机制（read-ahead）对连续读最有效；若必须随机访问，可考虑
MappedByteBuffer（见下文） - 不要绕过内核缓冲：避免使用
O_DIRECT标志（Java 中需 JNI 调用），否则会跳过 Page Cache，反而降低小数据、重复读场景的性能
让写操作高效落入 Page Cache
Java 默认的 FileChannel.write() 或 OutputStream.write() 都是“写入 Page Cache”，而非直写磁盘——这是高性能的前提。
- 批量写入：单字节或小 buffer 写入会产生大量系统调用开销，并可能触发频繁脏页回写；改用
ByteBuffer.allocateDirect(4096)或更大尺寸，填满后一次性channel.write(buffer) - 避免强制同步：除非强一致性要求，慎用
channel.force(true)；它会阻塞等待刷盘完成，彻底失去 Page Cache 的异步优势 - 写完即走，不等落盘：Kafka 正是靠这种“写入即返回 + 副本冗余”实现高吞吐；Java 应用也应接受“短暂不一致”，靠业务层或架构层兜底
用 MappedByteBuffer 主动对接 Page Cache
MappedByteBuffer 是 Java 提供的最贴近 Page Cache 的接口，它将文件区域直接映射到用户空间虚拟内存，读写操作本质就是访问 Page Cache 中的页。
- 适合中大文件、随机读写场景（如索引文件、日志位点管理）
- 映射时指定起始位置为 4096 的倍数（如
channel.map(READ_WRITE, 0, size)），有助于与底层 SSD 扇区对齐，减少读改写放大 - 注意：
force()在 mapped buffer 上仍表示刷盘，但多数情况下无需调用；JVM 退出或 OS 回收页时，脏页由内核自动 flush
配合系统级优化增强效果
Page Cache 效能还依赖运行环境配置：
- 确保 JVM 运行在有足够空闲内存的机器上——Page Cache 会动态占用未被应用使用的物理内存，内存不足时会被内核回收
- 避免其他进程大量缓存污染：如数据库、备份工具频繁读大文件，会挤占 Kafka 或你的应用所需缓存空间
- Linux 参数可调优：
vm.swappiness=1减少 swap 倾向，vm.vfs_cache_pressure控制 dentry/inode 缓存回收强度，间接影响 Page Cache 稳定性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
