自愿上下文切换（vcsw/s）指进程主动让出cpu，如调用sleep()、read()或等待锁/信号量等；pidstat -w中该值高而ccsw/s低，通常表明i/o阻塞或锁竞争，而非cpu瓶颈。
pidstat -w 输出里 voluntary context switches 是什么
自愿上下文切换（voluntary context switch）指进程主动让出 CPU，比如调用 sleep()、read() 等阻塞系统调用，或等待锁、信号量、子进程退出等资源就绪。它不等于“性能差”，但突增往往意味着 I/O 等待变长、锁竞争加剧，或程序逻辑频繁挂起。
关键点：
-
pidstat -w输出中的VCsw/s列就是每秒自愿上下文切换次数 - 它和
CCsw/s（非自愿切换）分开统计，后者才是时间片耗尽被强占的典型表现 - 同一进程若
VCsw/s高而CCsw/s低，大概率不是 CPU 瓶颈，而是卡在某类同步或 I/O 上
怎么用 pidstat -w 查看指定进程的自愿切换
最常用且精准的方式是结合 -p 和 -w，避免全量扫描干扰判断：
- 查单个进程：
pidstat -w -p 1234 1 5（每秒采样 1 次，共 5 次） - 查多个 PID：
pidstat -w -p 1234,5678 2（间隔 2 秒，持续输出） - 按命令名过滤：
pidstat -w -C "java" 3（匹配所有含 java 的命令行） - 加
-h让数字更易读：pidstat -w -h -p 1234 1（如显示 1.23K 而非 1234）
注意：pidstat 首次运行显示的是自系统启动以来的累计值；后续运行才显示“本次采样区间内增量”。所以至少执行两次才能看到真实速率。
VCsw/s 高但 CPU 使用率低，常见原因有哪些
这是典型的“CPU 不忙，但进程卡住”现象，VCsw/s 常作为第一线索：
- 文件或网络 I/O 阻塞：比如读慢盘、连不上远端服务、SSL 握手超时，
read()/connect()会触发自愿切换 - 锁竞争激烈：Java 应用中
synchronized或ReentrantLock争抢失败时线程挂起，计入 VCsw - GC 停顿期间线程阻塞：JVM Full GC 时应用线程全部进入 safepoint 并挂起，表现为大批量 VCsw 突增
- 数据库连接池耗尽：线程在
getConnection()上等待空闲连接，本质是条件变量等待
验证方法：配合 strace -p PID -e trace=epoll_wait,read,write,futex 看当前卡在哪类系统调用上。
和 vmstat 的 cs 值有什么区别
vmstat 的 cs 是系统级总和，无法定位到进程；pidstat -w 的 VCsw/s 是进程粒度且区分自愿/非自愿——这是关键差异。
-
vmstat 1显示cs达 20k，但你不知道是谁干的；pidstat -w 1可能发现只有 3 个 Java 进程贡献了 19k 的VCsw/s -
cs包含中断上下文切换、内核线程切换、进程/线程切换，而pidstat -w只统计用户进程的调度切换 - 高
cs+ 低VCsw/s？重点查硬件中断（cat /proc/interrupts）或软中断（pidstat -w -I在 SMP 下看 per-CPU 分布）
别只盯着 cs 数字本身，pidstat -w 才是把“谁在切、为什么切”拆开来看的最小可用工具。
