可行，但需绕过Go runtime栈展开干扰、禁用GC停顿污染，并显式启用硬件缓存事件；否则90%热点实为调度器或GC所致。
直接用 perf record 抓 Go 程序的 cache miss 是可行的，但必须绕过 Go runtime 的栈展开干扰、禁用 GC 停顿污染采样，并显式启用硬件缓存事件——否则你看到的 90% 的 “热点” 其实是调度器或垃圾回收器在忙，不是你的业务逻辑。
为什么 perf report 看不到 Go 热点函数，全是 runtime.mcall 或 gcBgMarkWorker？
Go 默认编译不带 -gcflags="-l"（即不内联）时，函数调用栈短；但更关键的是，perf record -g 依赖帧指针（frame pointer）做调用图还原，而 Go 1.17+ 默认关闭帧指针（-fno-omit-frame-pointer 被禁用）。结果就是 perf report 显示大量 [unknown] 或 runtime 函数占满顶部。
- 解决方法：编译时加
go build -gcflags="-l -N" -ldflags="-r ./"，强制保留调试符号和帧指针（注意-r ./防止 PIE 干扰地址解析） - 运行时补救：若无法重编译，可用
perf record -e cycles,instructions,cache-misses --call-graph dwarf强制用 DWARF 栈展开（需程序含 debug info） - 验证是否生效：跑完
perf report后，搜索你的业务函数名，应能定位到具体包路径如myapp.(*Processor).Handle，而非只看到runtime.goexit
如何正确采集 L1-dcache-load-misses 这类事件？
perf list 输出里看似有 l1d.replacement 或 mem_load_retired.l1_miss，但 x86 上并非所有 CPU 都支持细粒度缓存事件；ARM64 更可能直接不暴露 PERF_COUNT_HW_CACHE_*。盲目用 -e cache-misses 实际抓到的是 L3 或统一 cache miss，对定位 L1 行主序/伪共享问题意义不大。
- 先确认可用事件：
perf list | grep -i "l1.*miss\|dcache\|mem_load"，优先选mem_load_retired.l1_miss（Intel）或l1d.repl（AMD） - 避免用泛称：
-e cache-misses→ 改为-e mem_load_retired.l1_miss,instructions，确保事件可配对算 miss rate - 采样频率要够高：默认 4000Hz 不足以捕获短循环里的 cache 行颠簸，加
--freq=10000提升精度（但会增大数据量）
perf annotate 怎么看出哪条指令在反复 miss？
perf annotate 不是看函数总耗时，而是看每条汇编指令旁标注的采样占比和 cache miss 比例。Go 编译器生成的内存访问指令（如 MOVQ, LEAQ）如果右侧操作数是 (RAX)(RBX*8) 这类变址寻址，且 miss 率异常高，基本就是结构体字段布局或数组访问模式出了问题。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 执行命令：
perf record -e mem_load_retired.l1_miss,instructions -p $PID -- sleep 10 && perf report --no-children -M intel && perf annotate --symbol=myapp.(*Processor).Handle - 重点关注：标红的
mem_load_retired.l1_miss占比 >20% 的MOVQ指令，尤其是访问struct{ hot, cold int64 }中cold字段那条——说明热冷字段混布，一次加载把冷字段也拖进 cache line，浪费带宽 - 对比
instructions计数：若某行MOVQ的 instructions 计数很低但 miss 很高，说明它被高频执行且每次都不命中（典型如遍历链表节点）
Go 程序里怎么验证 cache 优化效果？
改完结构体字段顺序或改成 [][]int64 分块访问后，不能只看平均延迟下降——cache 优化的效果常体现在 P95/P99 毛刺收敛、CPU 利用率曲线变平滑。perf 的验证必须跨维度比对。
- 基线采集：
perf stat -e cycles,instructions,mem_load_retired.l1_miss -p $PID -- sleep 30，记下mem_load_retired.l1_miss / instructions比值 - 上线后复测同一负载，比对 miss rate 是否下降 30%+；若下降但延迟没变，检查是否引入了更多分支预测失败（加
-e branch-misses） - 警惕 false positive：Go 的
runtime.mapaccess1在 key 是字符串时，底层会调用memmove和哈希计算，这些也可能触发 cache miss——别一看到 miss 就去动你的业务结构体
最易被忽略的一点：Go 的 goroutine 调度是协作式的，perf record 抓到的 “on-CPU 时间” 可能包含大量 runtime 自身的标记扫描、栈复制开销。真正属于你代码的 cache miss，得在 perf report 里层层折叠掉 runtime. 前缀后，还能稳定出现在前 5 名的函数里，才值得动手改。
