线程上下文切换开销为1–3微秒，高频切换会显著消耗CPU时间；监控需关注cs、r队列长度及cswch/s与nvcswch/s三项指标；调优应收紧线程池规模并绑定关键线程至专用核心。
线程上下文切换本身不是问题，但频率过高会直接吃掉有效计算时间。关键不在于“有没有切换”，而在于“为什么切、切得是否必要、能不能少切”。
线程上下文切换的开销到底有多大
一次线程切换平均消耗 1–3 微秒，x86-64 平台典型值约 2 μs，ARM64 略低。这看似微不足道，但在高并发场景下极易累积：每秒 10 万次切换 ≈ 消耗 20% 的 CPU 时间，业务逻辑还没跑，内核已在忙于“搬家”。
开销主要来自两方面：
- 寄存器与栈状态保存/恢复：必须进入内核态完成，涉及 CPU 寄存器组、内核栈、TLS（线程本地存储）等切换
- CPU 缓存失效：L1/L2 缓存中缓存的指令和热点数据在切换后基本作废，新线程需重新加载，引发大量 cache miss 和内存访问延迟
必须盯住的三个核心监控指标
仅看 CPU 使用率会漏掉真实瓶颈。以下三项才是判断线程切换是否异常的黄金组合：
- cs（context switch）值：用 vmstat 1 查看，代表每秒总上下文切换次数。正常空闲系统为 25–40 次/秒；持续高于 10,000 次/秒需警惕；超过 50,000 次/秒大概率已成性能瓶颈
- r（runnable）队列长度：同一行中的 r 列，表示等待 CPU 的可运行任务数。若 r 值长期 > CPU 逻辑核心数，说明有线程在排队抢 CPU，是竞争加剧的直接信号
- pidstat -t 1 中的 cswch/s（线程级自愿切换）与 nvcswch/s（非自愿切换）：前者多由锁等待、sleep()、wait() 引发；后者多因时间片用尽被强制调度，反映 CPU 资源争抢激烈程度
最常见且有效的调优方向
多数线上系统的线程切换问题并非内核缺陷，而是应用层配置失当。以下两点见效最快：
- 收紧线程池规模：避免“一个连接一个线程”模型。最大线程数建议设为 CPU 核心数 × (1.5 ~ 2.5)，IO 密集型取上限，计算密集型取下限。线程数远超核心数时，公式 总切换次数 ∝ 线程数² / 核心数 开始生效
- 绑定关键线程到专用 CPU 核心：使用 taskset 或 Java 的 ThreadAffinity 库，为低延迟任务线程分配独占核心。这不仅减少切换，更避免缓存污染和 NUMA 跨节点访问延迟
别忽略的隐性诱因
有些切换行为藏得深，却贡献了大量 cs 值：
- 高频锁竞争：多个线程反复尝试获取同一把锁，失败后挂起 → 唤醒 → 再抢，形成“锁抖动”。可通过 perf record -e sched:sched_switch 追踪线程阻塞点
- 过度日志/监控打点：同步写日志（如 log4j 的 FileAppender）、频繁调用 System.nanoTime() 或 JMX 指标更新，都可能触发系统调用，间接拉高切换频次
- GC 停顿引发的线程集体让出：尤其是 CMS 或 ZGC 的某些阶段，会导致大量应用线程暂停并重新调度，表现为 cs 短时脉冲式飙升
