CPU上下文切换是操作系统中一种重要的机制，它指的是在多个进程或线程之间切换CPU控制的过程。这个过程涉及保存当前正在执行的进程或线程的状态（称为“上下文”），并加载另一个进程或线程的状态。这种切换使得操作系统能够在多个任务间高效地分配CPU资源。

所谓的上下文切换，就是把上一个任务的寄存器和计数器保存起来，然后加载新任务的寄存器和计数器，最后跳转到新任务的位置开始执行新任务。

根据任务的不同，CPU 的上下文切换就可以分为几个不同的场景，也就是进程上下文切换、线程上下文切换以及中断上下文切换。

具体步骤包括：

1. 保存当前上下文：将当前进程或线程的寄存器值、程序计数器、堆栈指针等信息保存到进程控制块（PCB）或线程控制块（TCB）中。

2. 选择下一个要运行的任务：操作系统根据调度算法选择下一个运行的进程或线程。

3. 加载新上下文：从选定的进程或线程的PCB/TCB中恢复其状态信息，如寄存器值和程序计数器等。

4. 切换到新任务：CPU开始执行新选择的进程或线程。

哪些因素会导致频繁的上下文切换？

1. 过多的进程或线程：系统中同时存在过多的进程或线程，会导致操作系统频繁地切换任务，以满足每个任务的执行需求。

2. 低优先级进程的竞争：如果多个低优先级进程在争用CPU资源，操作系统为平衡负载而频繁切换也可能导致频繁的上下文切换。

3. 短时任务：频繁出现在短时间内的快速任务，例如信号处理程序或小型计算任务，会导致上下文切换次数显著增加。

4. I/O操作：在需要等待I/O操作（例如磁盘读写或网络请求）时，进程会被挂起，操作系统会切换到其他进程，这种情形下，如果I/O操作非常频繁，将会导致上下文切换频繁发生。

5. 进程优先级变化：动态调整进程优先级（比如实时系统中的高优先级任务抢占低优先级任务），可能导致频繁的上下文切换。

6. 高频率的定时器中断：操作系统用定时器中断来实现时间片轮转调度，如果中断频率过高，会增加上下文切换的频率。

7. 资源锁竞争：多线程环境中，如果多个线程在争抢共享资源，可能导致线程不断被挂起和恢复，增加上下文切换。

上下文切换是实现多任务处理的关键，但频繁的上下文切换可能导致性能下降，因为它涉及一定的开销，包括保存和加载状态信息的时间。因此，操作系统通常会优化调度策略，以减少不必要的上下文切换。

2.1、系统调用上下文切换

Linux 进程既可以在用户空间运行，又可以在内核空间中运行。
当它在用户空间运行时，被称为进程的用户态；当它进入进入内核空间的时候，被称为进程的内核态
从用户态到内核态的转变过程，需要通过系统调用来完成
CPU 寄存器里原来的指令位置是在用户态。但是为了执行内核态代码，需要先把用户态的位置保存起来，然后寄存器更新为内核态指令的新位置。最后跳转到内核态运行内核任务。

当系统调用结束后，CPU 寄存器需要恢复原来保存的用户态位置，然后再切换到用户空间，继续运行进程。一次系统调用发生了两次 CPU 上下文切换！

系统调用过程中对用户态的资源没有任何影响，也不会切换进程，所以也称为特权模式切换。

2.2、进程上下文切换

进程是由内核来管理和调度的，所以进程的切换只发生在内核态。进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。

进程的上下文切换在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后再刷新进程的虚拟内存映射关系和用户栈，刷新虚拟内存映射就涉及到 TLB 快表 (虚拟地址缓存)，因此会影响内存的访问速度。

单次进程上下文切换的 CPU 时间在几十纳秒到数微秒之间。特别是在进程上下文切换次数较多的情况下，很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而影响 CPU 的实际使用率。

进程上下文切换的原因：

1. 为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行。（被动切换）

2. 进程在系统资源不足，这个时候进程也会被挂起，并由系统调度其他进程运行。（主动切换）

3. 当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度。

4. 当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行。

5. 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。

2.3、线程上下文切换

线程与进程的区别在于：线程是调度的基本单位，而进程是资源分配基本单位。内核中的任务调度，实际调度的是线程；而进程只是给线程提供了虚拟内存、全局变量等资源。

1. 当进程只有一个线程时，可以认为进程就等于线程。

2. 当进程拥有多个线程时，共享虚拟内存和全局变量等资源。这些资源在上下文切换时不需要修改。

3. 线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时需要保存。

线程的上下文切换分为两种：

1. 前后两个线程属于不同进程。此时，因为资源不共享，所以切换过程就跟进程上下文切换是一样。

2. 前后两个线程属于同一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据

2.4、中断上下文切换

为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行。

跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。中断上下文只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等。

过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行的时间，成了系统性能大幅下降的一个元凶。

常用的CPU性能监控工具有：perf, iostat, top, vmstat 等。

1. perf 是Linux内核自带的性能分析工具，能够对CPU的性能进行采样，分析应用的性能瓶颈。特点:

• 支持多种事件的监控，包括 CPU 周期、缓存命中率、分支预测等。

• 可生成详细的性能报告，帮助开发者找到瓶颈。

• 提供命令如 perf stat, perf record, perf report 等用于收集和分析数据。

• 提供 CPU 使用情况和各个设备的输入/输出统计。

• 有助于识别I/O瓶颈，优化存储设备的性能。

• 使用简单，常用于系统性能监视。

• 显示活动进程的实时列表，包括 CPU 使用率、内存使用率等。

• 可以按 CPU、内存等指标进行排序，方便用户监控系统负载。

• 提供交互式界面，可以杀死进程或改变其优先级。

• 报告系统的虚拟内存信息、进程、CPU活动等，帮助评估系统的性能。

• 提供内存、交换、I/O、系统和CPU等多维度的信息。

• 适合长时间监控和诊断。

• 可以监控各个CPU核心的使用情况，适合多核CPU的性能监控。

• 提供详细的用户、系统、空闲等CPU活动信息。

• 适合分析多核处理器的性能瓶颈。

• 可以定期收集CPU、内存、网络、I/O等各方面的性能数据。

• 能够生成历史数据，适合长期监控和分析。

• 一般配合 sysstat 包使用，支持多种统计项。

• 同时显示 CPU、I/O、网络、内存等统计信息，提供全面的视图。

• 提供实时数据，易于观察系统的当前状态。

• 可以输出成CSV格式，方便做后续分析。

vmstat基本使用：

vmstat [选项] [间隔] [次数]

间隔: 指定输出更新的秒数。
次数: 指定输出的行数。

例如：

# 每隔5秒输出1组数据
ubuntu:~$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache      si   so    bi   bo   in  cs   us  sy id   wa st
17  0     12 1179508 469892 3315788    0    0     6    20   49   74  0   0   99  0  0
16  0     12 1179376 469892 3315788    0    0     0     0 1048  678 100  0   0   0  0
16  0     12 1179376 469892 3315788    0    0     0     0 1045  675 100  0   0   0  0
16  0     12 1179376 469892 3315788    0    0     0     0 1047  685 100  0   0   0  0

运行vmstat命令后，输出的字段代表了不同的系统状态。以下是输出字段的具体含义：

上下文切换频率是多少次才是正常的？

使用sysbench来模拟系统多线程调度切换的情况。有命令，都默认以 root 用户运行，运行 sudo su root 命令切换到 root 用户。

1. 测试工具sysbench的安装：

   apt install sysbench
   

2. 使用vmstat查看空闲系统的上下文切换次数：

   # 间隔1秒后输出1组数据
   root@ubuntu:/home/fly# vmstat 1 1
   procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
    r  b   swpd   free   buff  cache      si   so    bi    bo   in   cs us sy id wa st
    0  0     12 1173896 470200 3318136    0    0     6     20   49   74  0  0 99  0  0
   

3. 在另一个终端开始压测：

   # 以10个线程运行5分钟的基准测试，模拟多线程切换的问题
   sysbench --num-threads=10 --max-time=300 --max-requests=10000000 --test=threads run
   

4. 使用vmstat查看：

   # 每隔1秒输出1组数据（需要Ctrl+C才结束）
   $ vmstat 1
   
   procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
    r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
    9  0      0 206356  67344 548616    0    0     0    14 1666 1596479  7 93  0  0  0
    7  0      0 206356  67344 548612    0    0     0     0 1680 1542861 10 90  0  0  0
    7  0      0 206356  67344 548612    0    0     0     0 1700 1550600 11 90  0  0  0
    7  0      0 206356  67344 548612    0    0     0     0 1704 1586618  9 91  0  0  0
    8  0      0 206356  67348 548612    0    0     0     8 1700 1493243  8 93  0  0  0
   

• cs 列：的上下文切换次数从之前的 35 骤然上升到了 139 万。

• r 列：就绪队列的长度已经到了 8，远远超过了系统 CPU 的个数 2，所以肯定会有大量的 CPU 竞争。

• us（user）和 sy（system）列：这两列的 CPU 使用率加起来上升到了 100%，其中系统 CPU 使用率，也就是 sy 列高达 84%，说明 CPU 主要是被内核占用了。

• in 列：中断次数也上升到了 1 万左右，说明中断处理也是个潜在的问题。

• 综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。

# 每隔1秒输出1组数据（需要 Ctrl+C 才结束）
# -w参数表示输出进程切换指标，而-u参数则表示输出CPU使用指标
$ pidstat -w -u 1

怪异的事儿：pidstat 输出的上下文切换次数，加起来也就几百，比 vmstat 的 139 万明显小了太多。这是怎么回事呢？难道是工具本身出了错吗？别着急，在怀疑工具之前，我们再来回想一下，前面讲到的几种上下文切换场景。其中有一点提到， Linux 调度的基本单位实际上是线程，而我们的场景 sysbench 模拟的也是线程的调度问题，那么，是不是 pidstat 忽略了线程的数据呢？

通过运行 man pidstat ，你会发现，pidstat 默认显示进程的指标数据，加上 -t 参数后，才会输出线程的指标。所以，我们可以在第三个终端里， Ctrl+C 停止刚才的 pidstat 命令，再加上 -t 参数，重试一下看看：

# 每隔1秒输出一组数据（需要 Ctrl+C 才结束）
# -wt 参数表示输出线程的上下文切换指标
$ pidstat -wt 1
    
08:14:05 UID TGID TID cswch/s nvcswch/s Command
...
08:14:05 0 10551 - 6.00 0.00 sysbench
08:14:05 0 - 10551 6.00 0.00 |__sysbench
08:14:05 0 - 10552 18911.00 103740.00 |__sysbench
08:14:05 0 - 10553 18915.00 100955.00 |__sysbench
08:14:05 0 - 10554 18827.00 103954.00 |__sysbench

现在你就能看到了，虽然 sysbench 进程（也就是主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。看来，上下文切换罪魁祸首，还是过多的 sysbench 线程，这也解释了：对于线程池而言，并不是开启的线程越多越好。

每秒上下文切换多少次才算正常呢？这个数值其实取决于系统本身的 CPU 性能。如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现了性能问题。

这时，你还需要根据上下文切换的类型，再做具体分析。比方说：

1. 自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题；

2. 非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈；

3. 中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件来分析具体的中断类型。