trace-cmd是分析C++多线程调度最可控方案，通过精准录制指定进程TID的sched_switch/wakeup/migrate事件，并结合kernelshark可视化或-F过滤分析，可真实还原内核调度行为，而perf sched因仅默认捕获主线程、漏掉yield/wait路径等缺陷不适用。
直接用 trace-cmd 抓取并分析 C++ 多线程调度行为，是目前最可控、信息最全的方案。它不依赖应用层打点，也不需要修改代码，能真实反映内核调度器对每个线程（TID）的决策过程。
如何用 trace-cmd 录制指定进程的所有线程调度事件
关键不是“录整个系统”，而是精准聚焦你的 C++ 进程及其子线程。先确认进程已启动且线程活跃（空闲线程几乎不触发 sched_switch）：
- 用
ps -T -p <pid></pid>查出所有业务线程的 TID 列表，确保它们正在运行中（状态为R或S） - 启用三个核心调度事件：
sched:sched_switch（上下文切换）、sched:sched_wakeup（唤醒）、sched:sched_migrate_task（跨 CPU 迁移） - 录制命令示例：
trace-cmd record -p sched -e sched:sched_switch -e sched:sched_wakeup -e sched:sched_migrate_task -P <pid></pid>，持续 10–20 秒足够捕捉典型行为 - 注意：若提示
No such file or directory，检查/sys/kernel/debug/tracing/events/sched/是否存在对应事件，缺失说明内核未开启CONFIG_SCHED_TRACER=y（主流发行版默认开启）
如何过滤出某个 C++ 子线程的调度轨迹
trace-cmd 原生支持按 TID 过滤，但必须在录制后用 trace-cmd report 配合 -F（filter）或脚本提取，不能靠 grep 简单匹配——因为原始 trace 数据含二进制字段和嵌套格式：
- 导出为文本便于分析：
trace-cmd report -F "comm == 'your_app_name' && tid == <tid></tid>" > thread_<tid></tid>.txt - 更推荐直接生成可被
kernelshark打开的.dat文件：trace-cmd record ...后执行trace-cmd extract -o trace.dat，再用kernelshark trace.dat可视化筛选特定 TID - 警惕
comm字段不可靠：C++ 线程名默认继承主进程名，需提前用pthread_setname_np()或prctl(PR_SET_NAME, ...)设置可识别名称，否则所有线程都显示为同一comm
为什么不能只依赖 perf sched 分析 C++ 线程调度
perf sched 表面看更轻量，但它对 C++ 多线程场景有本质缺陷：
立即学习“C++免费学习笔记（深入）”；
-
perf sched record -p <pid></pid>实际只捕获主线程（TID == PID）的调度事件，子线程的sched_switch默认被忽略，除非显式加--tid参数逐个指定——而你往往不知道哪些子线程正在活跃 -
perf sched latency --sort=avg --tid=<tid></tid>输出的“平均延迟”基于schedstat，该值仅统计入队等待时间（se.statistics.wait_sum），不包含唤醒后到实际运行前的抢占延迟（如被高优先级任务阻塞） - 当 C++ 线程频繁调用
std::this_thread::yield()或进入std::condition_variable::wait()，perf sched会漏掉这些非抢占式让出 CPU 的路径，而trace-cmd的sched_wakeup+sched_switch组合能完整还原唤醒-运行链路
真正难的是把 trace 数据映射回 C++ 业务逻辑：比如看到某 TID 在 CPU 3 上频繁迁移到 CPU 7，得结合线程创建时是否绑定了 cpu_set_t、是否启用了 NUMA-aware 内存分配，才能判断这是配置问题还是内核负载均衡策略所致。这类关联分析无法靠工具自动完成，必须人工交叉验证。
