c++标准库无法直接获取l1/l2缓存命中率，必须通过linux的perf_event_open系统调用访问硬件pmu事件，需root权限或调整perf_event_paranoid，绑定cpu核采样并计算派生指标。
C++ 标准库不提供任何直接获取 L1/L2 缓存命中率的接口，操作系统内核也不向用户态暴露实时缓存访问统计——这不是一个可编程“读取”的指标，而必须通过硬件性能计数器（PMC）采样并推算。
Linux 下用 perf_event_open 系统调用采集缓存事件
唯一可行路径是利用 Linux 的 perf_event_open 系统调用，绑定到当前线程（pid = 0, cpu = -1），监听硬件 PMU 事件，例如：
-
PERF_COUNT_HW_CACHE_L1D:READ:RESULT_ACCESS和PERF_COUNT_HW_CACHE_L1D:READ:RESULT_MISS -
PERF_COUNT_HW_CACHE_LL:READ:RESULT_ACCESS和PERF_COUNT_HW_CACHE_LL:READ:RESULT_MISS（LL 通常对应 L2/L3，具体取决于 CPU 架构）
注意：事件编号不是跨平台通用的，需用 perf list 查看本机支持项；ARM 与 x86_64 的编码不同，且部分老旧 CPU 不支持细粒度缓存事件。
需要 root 权限或 /proc/sys/kernel/perf_event_paranoid 设置为 ≤1
默认情况下，普通用户无法访问硬件 PMU——否则任意进程都能窃取其他进程的缓存行为特征。常见错误是程序运行时报 Operation not permitted，此时检查：
-
cat /proc/sys/kernel/perf_event_paranoid（值为 2 或更高即拒绝用户态 PMU） - 临时修复：
sudo sysctl -w kernel.perf_event_paranoid=1 - 永久生效需写入
/etc/sysctl.conf
即使有权限，perf_event_open 仍可能返回 -1 并设 errno = EBUSY——说明同一 CPU 上已有另一个 perf event 在占用该 PMU 寄存器，硬件计数器资源有限（通常每核仅 3–4 个通用寄存器）。
命中率只能靠两次 read() 差值计算，不能直接“获取趋势”
缓存命中率是派生指标：比如 L1D 命中率 ≈ (access - miss) / access，但必须在**同一时间段、同一 CPU 核上**连续采样，否则因线程迁移导致数据错位。实操要点：
- 调用
sched_setaffinity()将线程绑定到单个 CPU 核（如 CPU 0），避免跨核切换干扰计数器归属 - 用
ioctl(fd, PERF_IOC_REFRESH, 1)清零计数器后开始测量窗口 - 间隔固定时间（如 10ms）调用
read(fd, &buf, sizeof(buf))获取 4 个 uint64_t 值（access、miss、access、miss），再计算比值 - 不要用
CLOCK_MONOTONIC时间戳做分母——命中率是事件比例，不是“每秒命中次数”
所谓“趋势”只能靠你在应用层维护一个滑动窗口数组，存最近 N 次算出的命中率值，再绘图或告警——C++ 本身不负责这个。
Clang/GCC 编译时加 -march=native 未必提升精度
启用高级指令（如 rdpmc）并不能绕过内核 perf 框架——现代 Linux 强制所有 PMU 访问走 perf_event_open 路径，直接用 rdpmc 会触发 #GP 异常。即使你用 __builtin_ia32_rdtscp 测周期，也和缓存命中率无直接关系。真正影响精度的是：
- CPU 微架构：Intel Skylake+ 支持
MEM_LOAD_RETIRED.L1_HIT等更精确事件；老款 Core2 只能靠推测性统计 - 内核版本：5.4+ 对 AMD Zen2/3 的 L2 事件支持更完整；旧内核可能把 L2 miss 归入 LL miss
- 是否开启超线程：HT 启用时，两个逻辑核共享 L1D，事件计数可能混叠
没有“一键获取趋势”的 API，所有方案都依赖你手动绑定核、采样、校验事件可用性、处理溢出和迁移——最易被忽略的是线程迁移导致的计数器归属漂移，它会让命中率曲线突变，看起来像性能抖动，实际只是数据错位。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
