什么是上下文切换？为什么线程开多了反而变慢？

详细解析#

切换时保存什么#

Linux 里线程和进程都是调度实体，切换流程相同，区别只是同一进程的线程不用换页表，见 进程、线程和协程。

什么时候发生切换#

• 自愿切换：线程主动让出 CPU，比如等 I/O、等锁、sleep、等条件变量
• 非自愿切换：时间片用完，或者更高优先级的线程就绪，被调度器抢占

自愿切换多，说明线程经常在等资源（I/O、锁）；非自愿切换多，说明可运行的线程太多，在抢 CPU。

注意区分：系统调用只是同一个线程在用户态和内核态之间转换，不一定发生线程切换，见 用户态和内核态。

开销在哪里#

• 直接开销：进入内核、运行调度器选择下一个线程、保存和恢复寄存器、切换栈和页表
• 间接开销：L1/L2 缓存里是上一个线程的数据，新线程开始运行时大量缓存未命中；进程切换后 TLB 失效，访存要重新查页表。这部分通常比直接开销更大，也更难测量

线程开多了变慢，往往不只是切换本身：

1. 可运行线程远多于核数，每个线程分到的时间片变短，切换次数和缓存失效增加
2. 线程越多，锁竞争越激烈，大量线程在等锁、唤醒、再等锁
3. 每个线程都有栈和内核结构，占内存；线程数受 ulimit -u、kernel.threads-max、kernel.pid_max 等限制

CPU 调度算法简述#

Linux 的普通进程调度器长期是 CFS（完全公平调度），按虚拟运行时间挑最"欠" CPU 的任务；6.6 版本起换成了 EEVDF，在公平的基础上兼顾延迟。nice 值影响的是任务分到 CPU 时间的权重。

线程数怎么定#

• CPU 密集型（计算、压缩、加解密）：线程数接近 CPU 核数，再多也只是在抢 CPU
• I/O 密集型（调用数据库、下游接口）：线程大部分时间在等，可以比核数多，等待时间越长可以越多
• 网上常见的"核数 × (1 + 等待时间 / 计算时间)"只能当起点，实际还受锁、连接池大小、下游承受能力影响
• 正确做法：从估算值开始压测，逐步调整，观察吞吐、延迟、CPU 使用率和切换次数，找到吞吐不再上升的拐点。Java 线程池的配置见 线程池

另一个思路是不靠加线程提高并发：用事件循环（Node.js、Nginx、Redis）或协程（Go），少量线程就能处理大量连接。

代码示例#

# cs 列是系统每秒的上下文切换次数，in 是每秒中断次数，r 是可运行的任务数
vmstat 1

# 每个进程每秒的切换次数：cswch/s 是自愿切换，nvcswch/s 是非自愿切换（sysstat 包）
pidstat -w 1
# -t 细分到线程
pidstat -wt -p 1234 1

# 进程启动以来的累计切换次数
grep ctxt_switches /proc/1234/status

cs 的绝对值没有统一的"正常范围"，要和这台机器平时的基线对比。r 长期大于 CPU 核数、非自愿切换高，说明 CPU 不够用或线程太多；自愿切换高，要看是不是在等 I/O 或锁。

面试官可能追问#

易错点#

• 线程切换和进程切换的主要区别是要不要切页表，不是"线程切换不进内核"
• 不要背线程数公式，面试时说清思路，并强调要通过压测确定
• vmstat 的 cs 高不一定有问题，要结合 CPU 使用率、可运行队列长度和业务延迟一起看