最轻量方法是查/proc/[pid]/task/[tid]/status中的voluntary_ctxt_switches（主动让出）和nonvoluntary_ctxt_switches（被抢占）；需用syscall(sys_gettid)获取tid；voluntary高说明频繁阻塞，nonvoluntary突增且线程数远超cpu核数则可能过载。
查 /proc/[pid]/task/[tid]/status 看累计切换类型
这是最轻量、无需侵入代码的起点。每个线程对应一个 [tid]（注意不是 pthread_self()，得用 syscall(SYS_gettid) 获取），其 /proc/[pid]/task/[tid]/status 文件里有两行关键统计：
-
voluntary_ctxt_switches：线程主动让出 CPU 的次数，比如调用sleep()、pthread_mutex_lock()阻塞、epoll_wait()等待事件 -
nonvoluntary_ctxt_switches：被内核强制抢占的次数，常见于时间片耗尽、高优先级线程就绪、或调度延迟大
如果某个线程的 voluntary_ctxt_switches 显著偏高，说明它频繁进入阻塞态——重点检查锁竞争、IO 等待逻辑；若 nonvoluntary_ctxt_switches 突增且线程数远超 CPU 核心数，大概率是线程过载或调度压力大。
用 perf record -e sched:sched_switch 抓实时切换链路
当累计值只能告诉你“有多少”，而你需要知道“谁切到谁、在哪切、为什么切”时，必须用 perf。它不依赖程序修改，直接捕获内核 tracepoint 事件：
- 命令示例：
perf record -e sched:sched_switch -p $(pidof myapp) -- sleep 3 - 解析输出：
perf script会显示类似prev_comm=worker prev_pid=12345 prev_state=S ==> next_comm=io_thread next_pid=12346的行，其中prev_state=S表示前一线程因等待（如锁、IO）睡眠，R表示被抢占 - 注意：该采集开销不小，别长期开着；且
prev_state字段只在较新内核（≥4.10）中稳定可用
在 C++ 代码里用 getrusage(RUSAGE_THREAD) 做线程级轻量采样
如果你需要在运行时动态观察某条关键线程的切换趋势（比如 worker 线程池中的单个线程），getrusage(RUSAGE_THREAD) 是 POSIX 标准方案，开销极低：
- 它返回的
ru_nvcsw和ru_nivcsw字段分别对应非自愿/自愿切换次数，和/proc下的两个字段语义一致 - 适合嵌入性能热点路径做周期性打点，例如每 100 次请求调用一次，对比前后差值
- 缺点：无法定位切换发生的具体函数栈，仅提供计数；且
ru_nvcsw在某些旧内核上可能不更新（需确认内核版本 ≥2.6.23）
避开常见误判：voluntary 高 ≠ 代码写得差
很多人看到 voluntary_ctxt_switches 高就急着优化锁或 IO，但忽略了一个关键事实：线程模型本身决定了切换行为模式。例如：
- 使用
epoll+ 单线程事件循环时，voluntary_ctxt_switches几乎为 0——因为线程大部分时间在epoll_wait()中休眠，但那是高效等待，不是瓶颈 - 而 “one-thread-per-connection” 模型下，哪怕每个线程只做简单计算，
voluntary_ctxt_switches也会随连接数线性增长——问题不在单个线程，而在模型导致的线程总数失控 -
nonvoluntary高也不一定代表 CPU 不够：可能是某个线程持有锁太久，导致其他线程反复被抢占又立即抢回，形成“假性调度风暴”
真正要盯的，不是绝对数值，而是变化率与线程数、CPU 利用率的匹配关系——数值本身没意义，突变才有诊断价值。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
