pagecache是linux内核为提升磁盘i/o性能设计的统一文件数据缓存机制，以页为单位（通常4kb或8kb）缓存文件内容，读写操作默认经由它实现零拷贝加速、异步回写与跨进程共享。
PageCache 是 Linux 内核为提升磁盘 I/O 性能而设计的统一缓存机制，它不直接属于 JVM，却深刻影响 Java 程序中 BIO 和 NIO 的实际表现。JVM 本身不管理 PageCache，但所有文件读写操作（无论用 FileInputStream 还是 FileChannel）最终都经过内核路径，从而天然复用 PageCache。这种“间接支撑”不是 JVM 主动参与的结果，而是操作系统层面对 Java I/O 的底层赋能。
PageCache 如何默默加速 BIO 文件读写
BIO（如 FileInputStream + byte[]）执行 read() 时，JVM 发起系统调用，内核检查目标文件块是否已在 PageCache 中。若命中，数据直接从内存拷贝到 Java 堆缓冲区；若未命中，则触发磁盘读取并填充 PageCache，再完成拷贝。这意味着：
- 重复读同一文件段时，第二次起几乎无磁盘开销，仅剩一次内存拷贝（PageCache → 堆）
- 即使使用 BufferedInputStream，其内部缓冲仍是用户态预读，真正提速靠的还是 PageCache 的预加载与复用
- write() 同理：数据先落 PageCache（write-back 模式），由内核异步刷盘，应用线程不阻塞在物理写入上
NIO 的 DirectBuffer 与 PageCache 的协同关系
NIO 常用 ByteBuffer.allocateDirect() 创建堆外内存，但这并不绕过 PageCache——关键看具体操作：
- FileChannel.read(ByteBuffer)：若 ByteBuffer 是 direct 类型，内核仍先将数据载入 PageCache，再 DMA 拷贝至 direct memory。此时 PageCache 提供预读、合并写、脏页管理等能力
- MappedByteBuffer（mmap）：这是真正与 PageCache 深度绑定的方式。内存映射区域与文件页一一对应，修改即更新 PageCache，flush() 触发同步刷盘。没有额外拷贝，效率最高
- 单纯用 direct buffer 并不能跳过 PageCache；绕过它的典型方式是 sendfile() 或 splice() 系统调用（NIO 中通过 FileChannel.transferTo 实现）
为什么高并发场景下 PageCache 对 NIO 更关键
NIO 常用于单线程处理大量连接，每个连接频繁读小块数据（如 HTTP header、消息头）。这类随机读若无 PageCache 支撑，将导致大量磁盘寻道，彻底拖垮吞吐量：
- PageCache 自动聚合相邻读请求，减少实际 I/O 次数
- 内核基于 LRU/LFU 等策略保留热数据，使高频访问文件段长期驻留内存
- NIO 的非阻塞特性依赖内核快速返回就绪状态，而 PageCache 就绪 = 数据已备好，无需等待磁盘响应
开发中容易忽略的 PageCache 影响点
PageCache 的存在让某些行为“看起来正常”，实则掩盖隐患：
- 写后立即读可能读不到最新内容：因为 write() 只写入 PageCache，尚未刷盘；需显式调用 force() 或依赖 sync 策略
- 大文件顺序读性能飙升，但随机读仍受限于 PageCache 大小：当文件远超可用内存，PageCache 频繁换入换出，效果衰减
- 容器环境需注意 /proc/sys/vm/vfs_cache_pressure 等参数：资源受限时，内核可能优先回收 dentry/inode 缓存，间接影响 PageCache 效率
