上下文切换

上下文切换指的是内核（操作系统的核心）在CPU上对进程或者线程进行切换。上下文切换过程中的信息被保存在进程控制块（PCB-Process Control Block）中。PCB又被称作切换帧（SwitchFrame）。上下文切换的信息会一直被保存在CPU的内存中，直到被再次使用。

上下文切换定义

CPU 上下文切换

虽然系统的 CPU 个数有限，但能支持同时运行多个任务。当然这种同时只是宏观上的假象，如果从微观角度观察，会发现系统在不停轮流切换任务，使得每个任务都能获得运行的机会。

CPU 寄存器和程序计数器就是 CPU 上下文，因为它们都是 CPU 在运行任何任务前，必须的依赖环境。

CPU 是状态 + 存储的模型，其符合图灵机这种理想设备

内存
PC 指针指向下一条待运行的指令（状态）
计算规则
其他辅助计算的寄存器（状态）

多任务的每个任务都有自己的状态。当任务 1 切出，任务 2 切入时，CPU 的状态也要切换成任务 2 上一次切出时的状态，这样任务 2 才能继续运行。这些状态即是 CPU 上下文，CPU 上下文切换即保存和恢复 PC 和辅助计算的寄存器（也就是 CPU 寄存器和程序计数器）。

CPU 上下文切换的类型

根据任务的不同，可以分为以下三种类型:

进程上下文切换
线程上下文切换
中断上下文切换

进程上下文切换

发生进程上下文切换的场景

为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行。
进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行。
当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度。
当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行
发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。

进程/线程的CPU上下文切换成本来源

CPU 中的寄存器似乎一只手就数的过来，切换的成本非常小，为什么会造成系统负载显著升高呢？Linux 操作系统中的任务有进程和线程，切换的主要成本来自于进程/线程的上下文切换。

用户态和内核态的CPU上下文切换（特权模式切换）

现代处理器有很多个运行等级。比如在 x86 的保护模式中，有四种特权等级。Linux 使用 Ring 0 和 Ring 3：

Ring 0 是内核空间，具有最高权限，可访问所有硬件资源
Ring 3 是用户空间，权限最低，无法直接访问硬件资源

x86 保护模式下特权等级

用户态权限有限，无法直接操作所有寄存器，进程的切换只能由内核态来管理和调度，所以必然发生用户态 <==> 内核态的频繁转换。

而每个特权等级运行的代码不同，所以在切换用户态 <==> 内核态时，内核/用户空间本身的 CPU 上下文也需要互相切换。

从用户态到内核态的转变，需要通过系统调用来完成。比如，当我们查看文件内容时，就需要多次系统调用来完成：首先调用 open() 打开文件，然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出，最后再调用 close() 关闭文件。

用户态和内核态 CPU 上下文切换过程

保存 CPU 寄存器里原来用户态的指令位
为了执行内核态代码，CPU 寄存器需要更新为内核态指令的新位置。
跳转到内核态运行内核任务。
当系统调用结束后，CPU 寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行进程。

所以，一次系统调用的过程，其实是发生了两次 CPU 上下文切换。（用户态-内核态-用户态）。

不过，需要注意的是，系统调用过程中，并不会涉及到虚拟内存等进程用户态的资源，也不会切换进程。这跟我们通常所说的进程上下文切换是不一样的：进程上下文切换，是指从一个进程切换到另一个进程运行；而系统调用过程中一直是同一个进程在运行。

所以，系统调用过程通常称为特权模式切换，而不是上下文切换。系统调用属于同进程内的 CPU 上下文切换。但实际上，系统调用过程中，CPU 的上下文切换还是无法避免的。

进程上下文切换跟用户态和内核态的CPU上下文切换又有什么区别呢

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

因此，进程的上下文切换就比用户态和内核态的CPU上下文切换时多了一步：在保存内核态资源（当前进程的内核状态和 CPU 寄存器）之前，需要先把该进程的用户态资源（虚拟内存、栈等）保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。

如下图所示，保存上下文和恢复上下文的过程并不是“免费”的，需要内核在 CPU 上运行才能完成。

保存上下文和恢复上下文的过程

进程本身的数据结构庞大

Linux 中使用数据结构 task_struct 来描述进程所有的资源，其主要成员有进程状态、内核栈信息、进程使用状态、PID、优先级、锁、时间片、队列、信号量、内存管理信息、文件列表等等与进程管理、调度密切相关的信息。当切换进程运行，这些数据结构也需要保存和恢复。

虚拟内存

内核为每个进程提供了一个假象：进程都是独占地使用内存，这种独占是无法感知也无法使用其它进程的内存。

虚拟内存和实际的物理内存之间映射不是一个地址一个地址的映射，而是通过页表机制来实现。一页通常是 4096KB，这样的映射关系即为页表数据，为了减少页表数据的大小，会采用多级页表，比如 Linux 为了让进程支持 256T 内存，采用了四级页表。页表机制会带来额外的问题，页表本身也是存在内存里的，四级页表最坏情况下需要 5 次内存 IO 才能获取一个真正的内存数据。

为了让操作系统更快地操作虚拟内存，x86 处理器专门提供了 TLB(Translation Lookaside Buffer) 来管理虚拟内存到物理内存的映射关系。它可以理解为一个专用缓存，特点就是快，但缺点是存储的数据少，缓存有可能不命中。当系统发生进程切换，从进程 A 切换到进程 B，TLB 也必须刷新，那在刷新后，进程 B 必然会出现 TLB 不命中的情况，导致虚拟内存访问变慢。

由以上三点可见(特权模式切换，进程本身的数据结构庞大，虚拟内存)，进程上下文切换开销巨大，根据 Tsuna的测试报告，这一过程会持续数千纳秒。如果进程切换频繁，系统真正运行进程的时间便不够了。

线程上下文切换

在 Linux 的实现中，系统调度的基本单位其实是线程，进程是线程的集合，同一个进程的线程看到的虚拟内存是共享的，所以：

如果切换的两个线程分属不同的进程，因为资源不共享，其切换成本等同于进程上下文切换。
如果切换的两个线程属于同一个进程，因为虚拟内存是共享的，刷新 TLB 没有必要，切换成本也就少。

中断上下文切换

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

跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。所以，即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。中断上下文，其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等。

对同一个 CPU 来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上下文切换同时发生。同样道理，由于中断会打断正常进程的调度和执行，所以大部分中断处理程序都短小精悍，以便尽可能快的执行结束。

另外，跟进程上下文切换一样，中断上下文切换也需要消耗 CPU，切换次数过多也会耗费大量的 CPU，甚至严重降低系统的整体性能。所以，当你发现中断次数过多时，就需要注意去排查它是否会给你的系统带来严重的性能问题。

Go协程上下文切换

触发协程上下文切换的场景

协作式抢占的时候，检查抢占标志位，从而触发上下文切换
锁阻塞/channel阻塞/io阻塞等等，这类最后都会调用runtime.gopark将当前协程挂起，然后调度新的协程

需要保存上下文的有

与栈相关的SP和BP寄存器
PC寄存器
用于保存函数闭包的上下文信息，也就是DX寄存器

而对于其他通用寄存器，因为go的函数调用规约，参数和返回值是通过栈进行传递的，并且总是在函数调用的时候触发协程切换，并不需要保存