火焰图中函数名前缀可判断用户态或内核态：__libc_start_main、main等为用户态，sys_、do_、entry_、native_前缀多属内核态；perf record需加-g才能显示完整调用链，结合perf report -F comm,dso,symbol可双重验证态归属。
看火焰图里函数名前缀就能判断用户态还是内核态
火焰图本身不直接标注“用户态/内核态”，但函数命名习惯是可靠线索：__libc_start_main、main、std::vector::operator[] 这类全是用户代码；而 sys_epoll_wait、do_syscall_64、entry_SYSCALL_64、native_queued_spin_lock_slowpath 这些带 sys_、do_、entry_、native_ 前缀的，基本都是内核路径。特别注意 epoll_wait 在用户态调用，但火焰图里显示为 sys_epoll_wait，说明 perf 已进入内核执行阶段。
perf record 时加 -g 才能看到完整调用链
如果没加 -g，火焰图只显示顶层函数，根本分不清是用户代码在等系统调用，还是内核在忙。加了 -g 后，你会看到类似这样的栈：
main ├─ http_server::handle_request │ └─ boost::asio::io_context::run │ └─ epoll_wait │ └─ sys_epoll_wait ← 内核态起点 └─ std::thread::_State_impl<...>::execute
关键点：
-
epoll_wait是 libc 封装的用户态入口，它下面紧跟着sys_epoll_wait，就说明卡点在内核等待 I/O - 如果
sys_epoll_wait占比高，但上层用户函数（如handle_request）占比极低，说明 CPU 时间实际耗在内核调度或 I/O 等待上，不是你代码慢 - 若
malloc→brk→sys_brk频繁出现，说明内存分配成了瓶颈，且触发了系统调用开销
用 perf report -F comm,dso,symbol 快速确认态归属
火焰图是概览，真要快速验证某个热点属于哪一态，别翻 SVG，直接用命令行：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
perf report -F comm,dso,symbol | head -20
输出中三列含义：
-
comm：进程名（如myserver） -
dso：所属模块（[kernel.kallsyms]= 内核态，libpthread.so.0或可执行文件名 = 用户态） -
symbol：函数名（结合前缀 + dso 双重验证）
常见陷阱：
- 误把
pthread_mutex_lock当纯用户态——它底层可能调用futex→sys_futex，火焰图里会显示为futex→sys_futex，这时就是内核态阻塞 -
std::this_thread::sleep_for看似用户函数，实际调用clock_nanosleep→sys_clock_nanosleep，CPU 时间算在内核 - 某些编译器内联后，
std::string::c_str()消失，但调用它的writev可能暴露出sys_writev，得顺着栈往上看
真正难的是“混合态瓶颈”，比如锁竞争
最典型的是：火焰图里 pthread_mutex_lock 占比高，但它自己不耗 CPU；真正耗时的是线程在 sys_futex 上自旋或挂起。这时候你看到的是用户函数名，但问题根子在内核的 futex 实现和调度策略。这种场景下，单看函数名会误判——必须结合 perf stat 的 context-switches 和 task-clock 比值来交叉验证：如果上下文切换次数远高于预期，大概率是锁导致的内核态争抢。
