Linux下可通过/proc/[pid]/task/[tid]/status获取线程上下文切换累计值，voluntary_ctxt_switches和nonvoluntary_ctxt_switches分别统计主动让出与被抢占次数；perf record -e sched:sched_switch可抓取实时切换明细，getrusage(RUSAGE_THREAD)提供轻量级单线程切换计数。
Linux下用/proc/[pid]/status查线程上下文切换粗略统计
Linux内核本身不提供“每次切换的详细记录”（比如谁切到谁、在哪切的），但能给出累计统计值。最直接的方式是读取当前进程每个线程的/proc/[pid]/task/[tid]/status，关注voluntary_ctxt_switches和nonvoluntary_ctxt_switches两行。
这两个字段分别代表主动让出CPU（如等待IO、调用sched_yield()）和被强制抢占（如时间片用完、高优先级线程就绪）的次数。它们是自线程启动以来的累加值，不是实时快照。
-
voluntary_ctxt_switches偏高，通常说明线程频繁阻塞（比如密集调用read()、sleep()、锁竞争导致pthread_mutex_lock()挂起） -
nonvoluntary_ctxt_switches突增，更可能指向CPU资源紧张（调度延迟大）、线程优先级设置不合理，或存在严重锁争用（导致被抢占后又立即抢回） - 注意：
[tid]就是gettid()返回的值，不是pthread_self()——后者是POSIX线程ID，需用syscall(SYS_gettid)获取真实内核线程ID
用perf record -e sched:sched_switch抓实时切换事件
要看到“谁切到谁、何时切、在哪切”，必须用内核事件追踪工具。Linux perf 是最轻量且无需修改代码的方案，核心命令是：
perf record -e sched:sched_switch -p $(pidof your_program) -- sleep 5
执行后会生成perf.data，再用perf script解析。输出每行类似：
立即学习“C++免费学习笔记（深入）”；
your_program 12345 [001] ... 123456.789012: sched:sched_switch: prev_comm=worker prev_pid=12345 prev_prio=120 prev_state=S ==> next_comm=main next_pid=12346 next_prio=120
-
prev_state=S表示前一个线程处于可中断睡眠状态（常见于锁、IO等待）；R为运行态被抢占 - 该事件开销不小，长时间全量采集会影响程序性能，建议只在复现问题时短时间启用
- 不能直接在C++里调用
perfAPI获取这些数据——它本质是内核tracepoint + userspace ring buffer，C++程序需通过perf_event_open()系统调用自己读ring buffer，复杂度远超一般需求
C++里用getrusage(RUSAGE_THREAD)获取单线程切换计数
POSIX标准提供了getrusage()，传入RUSAGE_THREAD可查当前线程的资源使用情况，其中ru_nvcsw和ru_nivcsw字段对应非自愿/自愿上下文切换次数（与/proc里字段含义一致，但精度可能略低）。
示例用法：
struct rusage usage;
if (getrusage(RUSAGE_THREAD, &usage) == 0) {
long voluntary = usage.ru_nvcsw;
long involuntary = usage.ru_nivcsw;
}- 这个调用开销极小，适合周期性采样（比如每秒调一次），做趋势监控
- 注意：
ru_nvcsw是“non-voluntary”，ru_nivcsw才是“involuntary”——命名反直觉，别记混 - Windows下无等价接口，
GetThreadTimes()只给CPU时间，不包含切换统计
为什么没有“详细上下文切换日志”的标准API
因为上下文切换是内核调度器最底层操作，高频记录每次切换的完整上下文（寄存器、栈、时间戳、原因）会极大拖慢系统——现代CPU每秒可能切换上千次，日志写入本身就会触发更多切换。
所以所有方案都是妥协：
-
/proc和getrusage给总量，适合监控和告警 -
perf给明细，但必须离线分析，且影响性能 - 真正需要“函数级切换归因”（比如定位某次
std::mutex::lock()是否引发抢占），得结合perf record -e sched:sched_switch,syscalls:sys_enter_futex多事件关联，或用eBPF写定制跟踪器
多数场景下，先看nonvoluntary_ctxt_switches是否异常增长，再用perf抓几秒样本，比追求“全程详细日志”更实际。
