必须通过两次读取/proc/pid/stat第12字段majflt求差再除以时间间隔来计算每秒硬页错误次数，因该字段仅提供自启动以来的累计值，且解析时须跳过括号包裹的comm字段以避免错位。
硬页错误统计在 Linux 上只能通过 /proc/pid/stat 和 /proc/pid/status 间接估算
Linux 内核不直接暴露“每秒硬页错误数”的实时计数器，/proc/pid/stat 中的第 12 列（majflt）是**进程自启动以来累计的硬页错误次数**，不是瞬时速率。想得到“每秒”值，必须做两次采样并手动差分。
注意：majflt 统计的是该进程触发的、需要磁盘 I/O 的缺页异常（比如读取未缓存的 mmap 文件页、首次访问大页后备存储等），不包含软页错误（minflt），也不包含内核线程或子进程的硬页错误。
实操建议：
- 用
std::this_thread::sleep_for()控制采样间隔（如 1s），避免忙轮询 - 每次读取
/proc/self/stat（当前进程）或/proc/<pid>/stat（指定进程），解析第 12 个空格分隔字段 - 确保两次读取都成功，且时间差接近预期（避免因调度延迟导致误估）
- 第一次采样后等待至少 500ms 再读第二次，防止因采样太快而得到 0
解析 /proc/self/stat 的 majflt 字段要跳过括号内的 comm 字段
/proc/pid/stat 的第 2 字段是进程命令名（comm），它被括号包裹（如 (myapp)），会破坏空格分隔的字段序号。直接按空格切分会导致 majflt 被错判为第 13 或 14 列。
立即学习“C++免费学习笔记（深入）”；
正确做法是：先找到第一个右括号 ) 的位置，从它之后开始计数空格，第 11 个空格后的字段才是 majflt（因为括号前有 1 个字段，括号内 1 个字段，括号后到 majflt 还有 10 个字段，总计 12 字段偏移）。
示例代码片段（关键逻辑）：
std::ifstream stat{"/proc/self/stat"};
std::string line;
if (std::getline(stat, line)) {
size_t end_comm = line.find(')');
if (end_comm != std::string::npos) {
std::string tail = line.substr(end_comm + 1);
std::istringstream iss(tail);
std::string dummy;
// skip 10 fields: utime, stime, cutime, cstime, ... until majflt
for (int i = 0; i < 10; ++i) iss >> dummy;
long majflt = 0;
iss >> majflt; // this is the majflt value
}
}
硬页错误突增通常意味着内存压力或低效 mmap 使用
单纯获取数字没意义，关键看趋势和上下文。以下场景容易导致 majflt 飙升：
- 用
mmap()映射大文件但按随机地址访问（缺页时需从磁盘加载页） - 频繁
fork()后立即写大量 COW 内存（部分旧内核在写时可能触发硬页错误） - 使用透明大页（THP）但工作集远超可用 hugepage 数量，导致 fallback 到普通页+磁盘加载
- 内存不足时内核回收 page cache，后续再次访问文件又触发硬缺页
对比指标建议同时采集：/proc/meminfo 中的 MemAvailable、PageTables，以及 iostat -x 1 看 await 和 %util 是否同步升高——若磁盘响应延迟明显上升，才说明硬页错误真正在拖慢进程。
不要依赖 /proc/pid/status 中的 voluntary/involuntary context switches 来推断硬页错误
/proc/pid/status 里的 voluntary_ctxt_switches 和 nonvoluntary_ctxt_switches 和缺页无直接关系。硬页错误处理本身不必然导致上下文切换；它可能在中断上下文或当前进程上下文中完成（尤其在非阻塞路径下）。曾有人误以为 nonvoluntary_ctxt_switches 暴涨 = 硬页错误多，结果发现是锁竞争或定时器唤醒导致的。
唯一可靠来源仍是 /proc/pid/stat 的 majflt 字段。其他路径（如 eBPF、perf）能抓更细粒度事件，但需要 root 权限和额外工具链，不属于“C++ 直接获取”的范畴。
真正难的不是读数字，而是确认你看到的 majflt 增量是否真的来自你关心的内存访问模式——比如 mmap 文件的顺序读可能只触发一次硬页错误，后续页已在 page cache 中；而随机读每页都可能硬缺页。得结合访问 pattern 分析，不能只盯一个 per-second 数字。
