多线程抬高 major page faults 频率主因是并发线程分散内存分配引发硬缺页：线程a刚换入页面，线程b又在未映射地址new内存，尤其内存紧张或大页未对齐时需从swap/文件加载，导致majflt激增；单线程majflt≈0，8线程可飙至20+/sec，伴i/o wait与延迟抖动。
为什么多线程会抬高 major page faults 频率
不是线程本身“导致”页错误，而是多个线程并发访问分散的内存区域时，容易触发硬缺页（majflt）：当线程 A 刚把某页换入内存，线程 B 却在另一块未映射的虚拟地址上分配对象（比如 new 一块新内存），而该页尚未加载——尤其在物理内存紧张、或使用了大页（Huge Pages）但未对齐时，内核必须从 swap 或文件读取，造成 majflt 激增。常见现象是：单线程跑时 majflt ≈ 0，开 8 个线程后飙到 20+/sec，伴随明显 I/O wait 和响应延迟抖动。
用 std::pmr::monotonic_buffer_resource 减少每线程堆分配
高频 new 是 major fault 的主要诱因之一。多线程下每个线程都独立向系统申请小块内存，碎片化严重，且每次 brk/mmap 都可能触发新页映射。改用 per-thread 内存资源可批量预分配，避免反复系统调用：
- 每个线程启动时创建独立的
std::pmr::monotonic_buffer_resource，配一个 1MB~4MB 的std::pmr::synchronized_pool_resource或直接用std::pmr::new_delete_resource()做 fallback - 所有容器（如
std::vector、std::string）显式传入该 resource，例如：std::vector<int std::pmr::polymorphic_allocator>> v{&thread_resource}</int> - 线程退出前不手动释放——monotonic buffer 本身无
deallocate开销，整个 buffer 在栈/局部变量析构时一并归还
强制线程绑定 NUMA 节点 + madvise(MADV_HUGEPAGE)
跨 NUMA 节点访问内存不仅慢，还会增加 TLB miss 和 soft fault；而启用透明大页（THP）后，若线程分配的内存未对齐到 2MB 边界，内核仍会 fallback 到 4KB 页，失去大页优势。实操要点：
- 用
numactl --cpunodebind=0 --membind=0 ./your_program启动，或运行时调用set_mempolicy(MPOL_BIND, ...)锁定内存节点 - 在线程初始化阶段，对预分配的大块内存（如对象池底层数组）调用：
madvise(ptr, size, MADV_HUGEPAGE)，提示内核尽量用大页映射 - 确认 THP 已启用：
cat /sys/kernel/mm/transparent_hugepage/enabled应为always或madvise
监控时必须区分 minflt 和 majflt，且采样间隔 ≥100ms
误把 minflt 当瓶颈是常见误区——minor fault 只涉及页表更新，开销极低；真正要盯的是 majflt。但直接读 /proc/self/stat 得到的是累计值，必须做差分计算频率：
- 用
clock_gettime(CLOCK_MONOTONIC, &ts)获取时间戳，别用std::chrono::system_clock或usleep——后者无法保证实际休眠精度，会导致分母失真 - 字段解析必须跳过前 9 个字段，再取第 10（
minflt）和第 12（majflt），中间第 11 字段是cminflt（子进程 soft fault），不能跳过 - 采样间隔低于 100ms 会导致浮点除零风险、统计噪声放大，且
/proc/[pid]/stat文件本身更新有延迟，太密反而失真
真正难的是让所有线程的内存访问模式收敛到局部性高的区域——这需要结合对象池生命周期设计、缓存行对齐（alignas(64)）、以及避免 false sharing，否则光调参数只是治标。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
