Page Cache 是 Linux 文件读写的默认路径，非可选优化；它占用内存可被回收，导致 free -h 中可用内存减少，但系统不卡顿，本质是内核积极缓存文件数据。

Page Cache 不是“可选优化”，而是 Linux 文件读写的默认路径——几乎所有 read()、write()（非 O_DIRECT）都会经过它。理解它，不是为了调优炫技，而是避免误判内存使用、排查 I/O 延迟、读懂 free -h 里“可用内存”为何越来越小。

为什么 free 显示的可用内存越来越少？

这不是内存泄漏，是内核在积极缓存文件数据：Page Cache 占用的内存只要没被进程锁定（如 mlock()），就随时可被回收。当新内存申请到来，kswapd 会优先回收干净页（clean page），脏页（PG_dirty）则需先回写再释放。

• 现象：free -h 中 available 值低，但系统不卡顿 → 很可能只是 Page Cache 占得多
• 验证：看 /proc/meminfo 的 Cached: 和 Dirty: 行，或用 cat /sys/fs/cgroup/memory/memory.stat | grep -E "(cache|dirty)"（cgroup v1）
• 误区：手动执行 echo 3 > /proc/sys/vm/drop_caches 清缓存 → 短期释放内存，但立刻被新读写填满；且会引发后续大量磁盘读，反而拖慢响应

read() 和 write() 怎么走 Page Cache？

所有带缓冲的文件 I/O 都默认走 Page Cache，核心逻辑由 VFS 层统一调度，不依赖具体文件系统。

• read() 路径：
  → 查 address_space 的 xarray（旧内核为 radix tree）找 struct page（按 inode + offset/page_index 定位）
  → 命中且 PG_uptodate==1 → 直接 copy_to_user()
  → 未命中 → 分配页 → 发起磁盘 BIO → 完成后置 PG_uptodate=1 → 加入 LRU
• write() 路径：
  → 找/分配对应页 → copy_from_user() 写入 → 标记 PG_dirty=1 → 返回（不等刷盘）
  → 脏页由后台 writeback 线程异步刷出，触发条件包括：vm.dirty_ratio（如 20%）、vm.dirty_expire_centisecs（如 3000 = 30 秒）
• 注意：pwrite()、memcpy 到 mmap(MAP_SHARED) 区域，同样生成脏页，行为一致

哪些操作会绕过 Page Cache？

绕过 ≠ 更快，而是换一种一致性模型。绕过意味着放弃缓存收益，直面磁盘延迟。

• O_DIRECT：open 时指定 → read()/write() 绕过 Page Cache，直接与块层交互；要求用户 buffer 地址对齐（memalign(4096, size)）、长度对齐（4KB 倍数）；常见于数据库 WAL 日志写入
• O_SYNC 或 fsync()：不绕过缓存，但强制等待脏页刷盘完成 → 增加延迟，保障持久性
• Direct I/O + O_SYNC 组合：既绕缓存又等落盘 → 最强持久性，最低吞吐，慎用
• 错误认知：“dd iflag=direct 就一定不进 Page Cache” → 实际上 dd 的输入文件若未开 O_DIRECT，仍会走 cache；输出设备才决定是否 bypass

如何观察和简单干预 Page Cache 行为？

别迷信“清缓存”，重点看它是否健康工作：命中率高不高？脏页堆积严不严重？

• 查命中率：cat /proc/vmstat | grep -E "pgpgin|pgpgout|pgmajfault" → 用 pgmajfault（缺页中断）反推读缓存效率（越少越好）
• 控脏页节奏：
  

  sysctl -w vm.dirty_ratio=15
  sysctl -w vm.dirty_background_ratio=5

  → 降低触发后台回写的阈值，避免突发写导致阻塞
• 查某进程用了多少 Page Cache：grep -i "mm\/.*cache" /proc//smaps（含 Shared_Clean/Shared_Dirty）
• 关键提醒：Page Cache 是 per-file 的，多个进程打开同一文件，共享同一组缓存页（mapping 相同），但各自有独立 file->f_pos 偏移 —— 这正是 mmap 共享内存的基础

真正容易被忽略的，是 Page Cache 的“共享性”和“延迟可见性”：你改了一个 mmap 区域，另一个进程立刻能读到新值，不是因为 magic，而是它们访问的是同一个 struct page；而这个页何时落盘，完全由 writeback 策略决定，跟你的 msync() 调用与否、甚至进程是否退出都无必然关系。

# linux  # 可选  # 的是  # 多个  # 用了  # 得多  # 这不是  # 不高  # 很可能  # 更快  # 数据库  # 异步  # 线程  # node  # go  # app  # ai  # 为什么  # red  # echo  # 堆  # Struct  # 越好