perf record -g -f 99 -a ./your_app 再 perf report -n --no-children 可精准定位90% cpu瓶颈；-a采集所有线程，-g保留调用栈，避免多线程热点丢失和短时程序失效。
直接用 perf record -g -F 99 -a ./your_app，再 perf report -n --no-children，90% 的 CPU 瓶颈当场暴露。别先跑 gprof 或凭感觉猜——它漏模板、漏内联、对短时程序失效，还要求编译链接都带 -pg，稍错一步就白忙。
perf record 必须加 -g 和 -a 才能看清多线程热点
默认 perf record 只采主线程，哪怕你开了 16 个 worker 线程，perf report 里也只显示 main 和几个初始化函数。现象是：CPU 利用率 80%，但报告里 Overhead 最高的函数加起来不到 10%。
- 加
-a：采集全系统所有线程（适合调试进程内多线程） - 加
-p PID：更精准，避免其他进程干扰（适合高负载环境） - 必须加
-g：否则看不到调用栈，std::thread::join后面的真正耗时函数全被压平成 [unknown] - 短时程序（-F 99：默认 4KHz 采样太稀疏，容易漏掉关键帧
为什么 gprof 在多线程场景下基本失效
gprof 依赖函数入口插桩，而 C++ 多线程的典型热点恰恰是它看不见的：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 模板实例化函数（如
std::vector<int>::push_back</int>）不生成独立符号，不会出现在Flat profile - 内联函数（如
std::atomic::load）被展开后无调用点，插桩失效 - 线程启动函数（
std::thread构造器内部的pthread_create调用链）不在插桩范围内 - 运行时间 gmon.out 统计精度极差，
main常显示 0.0%
火焰图比文本 report 更容易揪出隐藏瓶颈
文本 perf report 显示单个函数耗时，但很多性能问题藏在“高频小函数”里。比如 std::string::c_str() 在循环中每轮调用一次，单次开销 20ns，文本里根本排不上号；但在火焰图上，它会横向铺满整个调用栈底部，一眼就能识别。
- 生成命令：
perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg - 关键检查点：
[unknown]占比高 → 缺-g编译或二进制被strip过 - 某一层特别“胖”（宽度异常大）→ 那里就是高频调用热点，哪怕函数名看着很 innocuous
- 多线程火焰图里出现大量平行分支 → 检查是否真有并行执行，还是线程在等锁空转
perf 数据不准？先确认这三件事
很多“perf 报告不准”的抱怨，其实源于环境配置错误：
- 编译没加
-g：函数名全变成[unknown]或地址，无法定位源码 - 用了
-O0：内联被禁用，调用栈失真；-O2或-O3才反映真实执行路径 - 在容器里跑
perf：cgroup 限制可能屏蔽硬件事件计数，优先在宿主机或privileged容器中运行
伪共享、锁竞争、上下文切换这些底层问题，perf 不会直接告诉你“这是 false sharing”，但它给出的缓存未命中率、cycles 与 instructions 比值、以及 sched:sched_switch 事件频次，都是指向具体根因的关键线索——得自己结合数据看。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
