最直接方式是解析/proc/self/task/[tid]/status文件，用syscall(sys_gettid)获取真实tid构造路径，逐行匹配voluntary_ctxt_switches:和nonvoluntary_ctxt_switches:前缀提取累计值，二者之和即线程自启动以来总切换次数。
怎么读取/proc/self/task/[tid]/status获取线程级切换次数
最直接的方式是解析当前线程专属的 /proc/self/task/[tid]/status 文件，其中 [tid] 必须用 syscall(SYS_gettid) 获取——别用 pthread_self()，它返回的是 POSIX 线程 ID，和内核线程 ID 完全不同。
关键字段只有两行：voluntary_ctxt_switches（主动让出，如锁等待、sleep()）和 nonvoluntary_ctxt_switches（被抢占，如时间片耗尽）。它们是自线程启动以来的累计值，不是瞬时速率。
- 路径拼接示例：
"/proc/self/task/" + std::to_string(syscall(SYS_gettid)) + "/status" - 必须逐行匹配前缀，不能依赖行号——内核不保证字段顺序
- 解析时用
line.rfind("voluntary_ctxt_switches:", 0) == 0判断开头，再找冒号位置提取数值，避免因空格/制表符数量变化导致substr()越界 - 若线程已退出，
open()会失败（ENOENT），需检查ifstream::is_open()并合理降级处理
为什么 getrusage(RUSAGE_THREAD, &ru) 多数情况下返回 0
getrusage(RUSAGE_THREAD, &ru) 理论上能拿到 ru.ru_nvcsw 和 ru.ru_nivcsw，但实际在主流发行版（glibc ≥2.31 + kernel ≥5.4）中几乎总是 0。这不是你调用错了，而是内核压根没往这个系统调用里填线程级数据——只保证 RUSAGE_SELF（进程级）有效。
- 即使某次读到非零值，也不能当作稳定行为，属未文档化实现细节
- 它不区分“当前线程”和“调用线程”，若在信号处理函数或 fork 后子进程中调用，结果不可预测
- 相比
/proc/self/task/[tid]/status，它更轻量但不可靠；后者虽要开文件，但数据真实、可验证
perf record -e sched:sched_switch 能看到什么
想定位“谁切到谁、在哪切、为什么切”，必须用 perf 抓取 sched:sched_switch 事件。它不给总数，但提供每次切换的完整上下文：
- 输出样例：
worker 12345 [001] 123456.789012: sched:sched_switch: prev_comm=worker prev_pid=12345 prev_state=S ==> next_comm=main next_pid=12346 -
prev_state=S表示前一个线程在可中断睡眠（常见于锁、IO），R表示被抢占时正在运行 - 命令示例：
perf record -e sched:sched_switch -p $(pidof your_program) -- sleep 2，注意需 root 权限，且长时间采集会明显拖慢目标程序 - 它无法告诉你单次切换花了多少 CPU 周期——那得搭配
cycles事件做交叉分析，复杂度高得多
监控时最容易忽略的三个细节
高频读 /proc 不是零开销：每次 open()/read() 都触发内核路径查找和字符串扫描。10ms 级采样会让 CPU 占用率异常升高，尤其在线程数多的程序中。
- 采样间隔建议 100ms–1s；低于 100ms 收益极小，噪声反而主导结果
- 别反复
new/deletestd::ifstream对象——复用同一个对象，用seekg(0)重置读取位置更轻量 - 如果程序跑在容器里，确认
/proc是以rw挂载的，否则open()会静默失败（errno = EROFS）
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
