操作系统

用户态和内核态

Kernel 运行在超级权限模式（Supervisor Mode）下，所以拥有很高的权限。按照权限管理的原则，多数应用程序应该运行在最小权限下。因此，很多操作系统，将内存分成了两个区域：

• 内核空间（Kernal Space），这个空间只有内核程序可以访问；
• 用户空间（User Space），这部分内存专门给应用程序使用。

内核空间和用户空间，分别对应着下图中， CPU 特权等级的 Ring 0 和 Ring 3。

用户态和内核态

用户空间中的代码被限制了只能使用一个局部的内存空间，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源，我们说这些程序在用户态（User Mode） 执行。内核空间中的代码可以访问所有内存，我们称这些程序在内核态（Kernal Mode） 执行。

系统调用

系统调用是指使用类似函数调用的方式调用操作系统提供的 API。

本质是用户程序通过特定机制（Trap，Trap 其实也是一种中断）将控制权交给操作系统内核，由内核执行特权操作。

系统调用的执行分为两部分：

1. 用户程序发起请求

通过软中断或专用指令（如 syscall）触发内核的介入。

不是直接执行内核代码，而是通过中断/指令通知内核：“请帮我执行某个特权操作”。

2. 内核执行实际操作

CPU 切换到内核态后，内核根据系统调用号（如 SYS_read）从系统调用表中找到对应的内核函数（如 sys_read）。

内核函数由操作系统实现，直接操作硬件或管理资源（例如从磁盘读取数据到内存）。

执行完毕后，内核将结果返回给用户程序。

系统调用的过程有没有发生 CPU 上下文的切换？

答案是肯定的。

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

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

系统调用过程通常称为特权模式切换，而不是上下文切换。系统调用过程中，CPU 的上下文切换还是无法避免的。

Go 系统调用

Go 语言的标准库（如 os、net、syscall）封装了系统调用，但其底层实现涉及：

• 用户代码调用标准库（如 os.Read、net.Dial）。
• 标准库调用 syscall 包，封装系统调用号（如 SYS_READ、SYS_WRITE）。
• Go Runtime 介入，处理系统调用的阻塞和调度问题。

操作系统进程调度

线程调度的方法

先到先服务

早期的操作系统是一个个处理作业（Job），比如很多保险业务，每处理一个称为一个作业（Job）。处理作业最容易想到的就是先到先服务（First Come First Service，FCFS），也就是先到的作业先被计算，后到的作业，排队进行。

这里需要用到一个叫作队列的数据结构，具有先入先出（First In First Out，FIFO）性质。先进入队列的作业，先处理，因此从公平性来说，这个算法非常朴素。另外，一个作业完全完成才会进入下一个作业，作业之间不会发生切换，从吞吐量上说，是最优的——因为没有额外开销。

问题：一个 job 如果需要一天的时间，后面是一个用时 10 分钟的 job，10 分钟的 job 要等前面的 job 完成，才能运行，这种情况，先到先服务算法就不适用了。

解决办法：短作业优先。

短作业优先

预估 job 运行的时间，短的作业优先运行。

例如，有三个 job，预估运行时间分别是 10 分钟、20 分钟、30 分钟。

1. 先运行 10 分钟的 job。
2. 然后运行 20 分钟的 job。
3. 最后运行 30 分钟的 job。

长作业和短作业之间也没有切换，从响应时间上说，是最优的。

平均等待时间 = 总等待时间/任务数

平均等待时间和用户满意度是成反比的，等待时间越长，用户越不满意，因此在大多数情况下，应该优先处理用时少的，从而降低平均等待时长。

问题：

1. 紧急任务如何插队？
2. 等待太久的任务如何插队？
3. 先执行的大任务导致后面来的小任务没有执行如何处理？比如先处理了一个 1 天才能完成的任务，工作半天后才发现预估时间 1 分钟的任务也到来了。

解决方案：

• 优先级队列
• 抢占

优先级队列

优先级队列可以给队列中每个元素一个优先级，优先级越高的任务就会被先执行。

优先级队列的一种实现方法就是用到了堆（Heap）这种数据结构，更最简单的实现方法，就是每次扫描一遍整个队列找到优先级最高的任务。也就是说，堆（Heap）可以帮助你在 O(1) 的时间复杂度内查找到最大优先级的元素。

1. 对于紧急的任务，就给一个更高的优先级。
2. 而对于普通任务，可以在等待时间（W） 和预估执行时间（P） 中，找一个数学关系来描述。比如：优先级 = W/P。W 越大，或者 P 越小，就越排在前面。

紧急任务如何插队？等待太久的任务如何插队？这两个问题就都解决了。

那么看先执行的大任务导致后面来的小任务没有执行的情况如何处理？

就需要抢占了。

抢占

抢占就是把执行能力分时，分成时间片段。让每个任务都执行一个时间片段。如果在时间片段内，任务完成，那么就调度下一个任务。如果任务没有执行完成，则中断任务，让任务重新排队，调度下一个任务。

还有一些问题可以进一步优化：

1. 如果一个线程优先级非常高，其实没必要再抢占，因为无论如何调度，下一个时间片段还是给它。那么这种情况如何实现？
2. 如果希望实现最短作业优先的抢占，就必须知道每个线程的执行时间，而这个时间是不可预估的，那么这种情况又应该如何处理？

多级队列模型

多级队列，就是多个队列执行调度。如图：

两个优先级不同的队列，只要上层队列有任务，下层队列就会让出执行权限。

• 低优先级队列可以考虑 抢占 + 优先级队列 的方式实现，这样每次执行一个时间片段就可以判断一下高优先级的队列中是否有任务。
• 高优先级队列可以考虑用 非抢占（每个任务执行完才执行下一个）+ 优先级队列 实现，这样紧急任务优先级有个区分。如果遇到十万火急的情况，就可以优先处理这个任务。

但是还是没有解决短任务先行的问题。

可以考虑再增加一些队列，让级别更多：

• 紧急任务仍然走高优队列，非抢占执行。
• 普通任务先放到优先级仅次于高优任务的队列中，并且只分配很小的时间片；如果没有执行完成，说明任务不是很短，就将任务下调一层。
• 下面一层，最低优先级的队列中时间片很大，长任务就有更大的时间片可以用。

通过这种方式，短任务会在更高优先级的队列中执行完成，长任务优先级会下调，也就类似实现了最短作业优先的问题。

实际操作中，可以有 n 层，一层层把大任务筛选出来。 最长的任务，放到最闲的时间去执行。

进程在什么时候才会被调度到 CPU 上运行？

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

2. 进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起（阻塞态，Blocked），并由系统调度其他进程运行。

3. 当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时（可中断的阻塞态，Interruptible Sleep），自然也会重新调度。

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

5. 发生硬件中断时，CPU 上的进程会被中断挂起（可能有两种状态，时间片耗尽了就是就绪态，如果在等待资源，就会进入阻塞态），转而执行内核中的中断服务程序。

进程上下文切换

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

进程的上下文切换比系统调用时多了一步：

1. 保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；
2. 加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。

线程上下文切换

线程与进程最大的区别在于，线程是调度的基本单位，而进程则是资源拥有的基本单位。

所谓内核中的任务调度，实际上的调度对象是线程；而进程只是给线程提供了虚拟内存、全局变量等资源。

• 当进程只有一个线程时，可以认为进程就等于线程。
• 当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的。
• 另外，线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的。

线程的上下文切换其实就可以分为两种情况：

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

中断上下文切换

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

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

对同一个 CPU 来说，中断处理比进程拥有更高的优先级。所以中断上下文切换并不会与进程上下文切换同时发生。

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

上下文切换时的状态保存

上下文切换时，需要保存和恢复 CPU 寄存器、内核栈、硬件中断参数等数据。

上下文被保存在内核为该线程分配的 “内核栈” 中，或者结构体中，如 task_struct（Linux）内的寄存器保存区。

在 Linux 中，每个线程（task）都有一个内核维护的结构体 task_struct，用来记录这个线程的上下文状态。

寄存器的值并不是随便保存在某块用户内存中，而是：

1. 保存到内核栈中（每个线程也有一个内核栈，通常大小为 8KB）。
2. 或者在 task_struct 中的一个子结构体（如 thread_struct）里保留寄存器备份区。

重新调度线程上 CPU 时，通过调度器维护的指针，例如 task_struct 指针从内核栈中恢复这些寄存器的值，这样才能让线程从上次的状态继续执行。

操作系统何时在 CPU 上执行

操作系统是一个事件驱动的核心控制器，不会一直占用 CPU，它在下面这些场景中才会执行：

1. 系统启动阶段

• 开机后，BIOS/UEFI 加载引导程序 → 加载 OS 内核 → 内核初始化并接管 CPU。

2. 中断发生时（包括硬件和软件中断）

• 键盘敲击、时钟中断、网卡收包等 → 内核响应中断处理逻辑。
• 时钟中断触发调度器，操作系统决定哪个进程/线程接下来使用 CPU。
• 例如程序访问未映射的内存页，触发 page fault → 进入内核做缺页处理。

3. 系统调用：系统调用使用了“软件中断指令”，如 int 0x80，但在内核中，它被归类为“陷阱tra）” 而非 “中断 interrupt”。

• 包括用户态程序执行系统调用。如文件读写、内存分配、进程创建等，会陷入内核态，内核执行对应的逻辑。

中断

中断 (Interrupt) 是操作系统和硬件之间进行通信的一种方式。它的作用是：

当 CPU 正在处理某个任务时，如果有“更紧急”的事件发生，可以暂时打断当前任务，先去处理这个事件，处理完再回来继续干原来的事。

一个完整的中断处理机制，通常包括以下几个部分：

• 中断源：谁发起了中断？比如：键盘敲击、网络数据到达、磁盘读写完成等。
• 中断控制器（PIC/APIC）：负责管理多个中断源的请求，判断谁优先。
• 中断向量表：中断号 → 中断处理函数的地址映射表。
• 中断处理程序（ISR）：具体处理这个中断的代码逻辑。

中断分类

不同类型的实现机制和触发机制不同。但目的和最终效果一样：都是为了产生一个信号，从而让 CPU 暂止当前正在运行的程序、转而去执行中断处理程序、执行完之后再返回继续执行原程序。

时钟中断

时钟中断（Timer Interrupt）是操作系统中的一个重要机制，它由硬件定时器定期触发。每次时钟中断，操作系统都会执行一系列任务，例如：

1. 时间管理（更新系统时间）
2. 进程调度，CPU 实际上只能同时运行一个进程（多核 CPU 也是每个核运行一个进程），通过时钟中断，每隔 10ms 就暂停当前进程，切换到下一个进程运行。这个过程称为 时间片轮转调度（Round Robin Scheduling）。
3. 睡眠管理
4. 看门狗机制（检测系统死锁）

时钟中断是周期性发生的，操作系统依赖它来维持时间流动和任务管理。如果没有它，系统将会“停滞”在某个任务中，无法切换进程，也无法正确处理延时任务。

时钟中断的触发频率

时钟中断的频率由 PIT 计时器设定，通常 OS 选择：

• 10ms（100Hz）：Linux、Windows 默认值
• 1ms（1000Hz）：实时系统（RTOS）

线程栈

在 Linux 操作系统中执行 pthread_create 系统调用，进程会启动一个新的线程，如果用户没有通过软资源限制 RLIMIT_STACK 指定线程栈的大小，那么操作系统会根据架构选择不同的默认栈大小。多数架构上默认栈大小都在 2~4MB 左右，极少数架构会使用 32 MB 的栈。例如 x86_64 架构是 2MB。

线程栈的缺点：

• 这个固定的栈大小在某些场景下不是合适的，如果程序需要同时运行几百个甚至上千个线程，会占用大量的内存空间，这对操作系统来说是一种负担。
• 当函数的调用栈非常深时，固定栈大小也无法满足用户程序的需求。

每个线程栈空间互不重叠，独立分配，位于进程虚拟地址空间不同区域。

主线程的栈是进程启动时由内核分配的；

子线程的栈由 pthread_create 时另行分配，不依赖主线程的栈。

goroutine

Go goroutine 的调度系统是建立在操作系统线程之上的。

pthread_create 系统调用创建的线程是内核态线程，Go 实现了用户态线程 goroutine。所有的线程都要自己调度（相当于操作系统调度进程的主线程；进程的主线程进行二级调度，调度自己内部的线程）。但是它的额外开销和默认栈大小都比线程小很多。

goroutine 的栈空间并不是由操作系统分配，而是 Go 自己管理的：

• goroutine 的初始栈很小只有 2KB。这个初始栈由 Go runtime 在堆（heap）上分配，不是在线程栈上分配！