perf record 默认不采集用户态调用栈，需加 -g 启用 DWARF 回溯（依赖调试符号）或 --call-graph fp（需保留帧指针）；内核栈需 root 权限并限定用户态事件；符号未解析则因 debuginfo 缺失、库路径不匹配或运行时（如 Java）未启用 perf 支持。
perf record 采样时为什么没抓到函数调用栈？
默认情况下 perf record 不采集用户态调用栈，尤其在没有调试符号、或程序被 strip 过时，perf report 只能看到 [unknown] 或 __libc_start_main 这类泛化入口。
必须显式开启栈展开，并确保环境支持：
- 加
-g（等价于--call-graph dwarf）启用 DWARF 栈回溯，依赖可执行文件含调试信息（debuginfo包或编译时加-g） - 若无调试信息，可退而求其次用
--call-graph fp（帧指针模式），但要求程序编译时未加-fno-omit-frame-pointer - 内核态栈默认不展开，需 root 权限 +
perf record -g -e cycles:u（加:u限定用户态）避免混入大量内核噪声
perf report 看不到具体函数名，只显示地址？
这是符号未解析的典型表现，不是 perf 坏了，而是它找不到对应的符号表。
常见原因和解法：
- 目标进程是动态链接的，但
/proc/<pid>/maps中的库路径已卸载或版本不匹配 → 用perf record --build-id记录构建 ID，再配合perf buildid-list和本地 debuginfo 匹配 - 程序用了
LD_PRELOAD或自定义 loader →perf record -d（启用 dwarf 解析）+ 确保 preload 的 so 有调试符号 - Java/Python 等运行时：需额外加载
libperf-jvmti.so或启用perf inject --jit，否则只看到0x7f...地址
perf top 实时监控时 CPU 占用飙高，还卡顿？
perf top 默认每秒采样 1000 次（-F 1000），对负载敏感的系统会明显拖慢目标进程，尤其在低频 CPU 或容器里。
更稳的做法：
- 先用
perf top -F 100降低采样频率，观察是否仍有代表性热点 - 改用
perf record -F 99 -g -- sleep 10录制固定窗口，再perf report分析，避免实时渲染开销 - 注意
perf top默认跟踪所有 CPU，加-C 0,1限定核心数，减少跨核中断干扰
分析 Java 应用时 perf 显示全是 [unknown] 或 libjvm 符号？
Java 方法名不会自动出现在 perf 符号表里，JIT 编译后的代码段不带标准 ELF 符号。
必须启用 JVM 的 perf event 支持：
- 启动 Java 时加参数：
-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints -XX:+PreserveFramePointer -XX:+UsePerfData - 确保 JVM 是 OpenJDK 8u262+ / 11+，且未禁用
perf相关选项（有些定制版 JDK 会关掉UsePerfData） - 运行后检查
/tmp/perf-<pid>.map是否生成，再执行perf inject --jit -i perf.data -o perf_jit.data合并符号
没走完这三步，perf report 就永远看不到 java.util.HashMap::get 这种真实方法名。
