vmstat的cs列是全系统每秒上下文切换总量，非单核平均值；4核机cs=8000可能集中于1核，需结合r>核数、us低sy高、pidstat -wt及perf定位跨核调度与线程级热点。
vmstat cs 列只能看总量，别把它当单核指标
vmstat 输出的 cs 是全系统每秒总切换次数，不是每个 CPU 核心的平均值。比如 4 核机器上 cs=8000，不等于每核 2000；它可能集中在 1 个核上跑满，其余 3 核空闲——这种不均衡本身就会放大调度开销。
真正要评估多核任务的上下文切换开销，得先确认是否真存在跨核调度压力：
-
r（就绪队列长度）持续 > CPU 总核数，说明有进程在排队等 CPU，但不等于均匀分布 -
us（用户态）低 +sy（内核态）高 +cs高 → 很可能是频繁进出内核导致的跨核迁移或锁争抢 - 用
top -H看线程级 CPU 分布，再结合ps -eo pid,comm,psr查每个线程绑定的 CPU（psr列），若同一进程的多个线程频繁跳核，说明没做 CPU 绑定或负载不均
pidstat -w 要配合 -t 和 -p 才能看清线程级切换来源
默认 pidstat -w 1 只显示进程粒度，但多核任务的瓶颈常在线程层。必须加 -t 查线程，或指定 -p PID 锁定目标进程：
-
pidstat -wt 1：输出带线程 ID（TID）的cswch/s和nvcswch/s，能发现某几个 worker 线程切换异常高 -
pidstat -w -p $(pgrep -f "java MyApp") 1：直接聚焦 Java 应用，避免被 systemd、ksoftirqd 等内核线程干扰 - 注意
cswch/s高通常对应 I/O 等待或锁阻塞；nvcswch/s高且%CPU低，大概率是时间片被抢走——这时要看是否线程数远超核数，或 GC 导致 safepoint 停顿
perf record -e context-switches 能定位跨核切换热点
perf 是少数能抓到具体切换事件发生在哪个 CPU 核上的工具，比统计类命令更接近硬件事实：
-
sudo perf record -e context-switches -a sleep 10：全局采集 10 秒，-a 表示所有 CPU -
sudo perf script | head -20：输出类似java 12345 [003] 123456.789: context-switches: 123456789012345: 0x12345678 -> 0x87654321，其中[003]就是发生切换的 CPU 编号 - 如果大量切换都落在
[000]或[001]，而其他核闲置，说明调度器没把负载摊开——这时候查/proc/sys/kernel/sched_migration_cost_ns和应用是否用了sched_setaffinity()
/proc/[pid]/status 里的 ctxt_switches 字段容易被误读
每个进程的 /proc/[pid]/status 中有 ctxt_switches 行，但它记录的是该进程**自启动以来的累计切换次数**，不是速率，也不区分自愿/非自愿：
- 数值本身无意义，比如看到
ctxt_switches: 12345678不能说明当前负载高，得隔几秒重复读取算差值 - 它不反映线程粒度——同一个进程下 10 个线程共切了 1000 次，这里只记作 1000，无法知道是 1 个线程切了 1000 次还是 10 个各切 100 次
- 真正要用它，得搭配
ps -T -p PID列出所有线程 TID，再逐个读/proc/[tid]/status，否则看不出多核任务里谁在拖后腿
cs 数值调优，可能绕开真正瓶颈。 
