用户态与内核态
特权级与 CPU 保护环
现代 CPU（以 x86 为例）提供了4 个特权级别，称为 Ring 0 ~ Ring 3。数字越小，权限越高：
┌───────────────────────┐
│ Ring 0 │ ← 内核态（最高权限）
│ 操作系统内核 │
├───────────────────────┤
│ Ring 1 / Ring 2 │ ← 几乎不使用
│ (设备驱动/服务) │
├───────────────────────┤
│ Ring 3 │ ← 用户态（最低权限）
│ 应用程序 │
└───────────────────────┘
大多数操作系统（包括 Linux）只使用了两个级别：
- Ring 0：内核态（Kernel Mode），运行操作系统内核代码
- Ring 3：用户态（User Mode），运行应用程序代码
为什么不用 Ring 1 和 Ring 2？因为 x86 的段保护机制过于复杂，大多数 OS 设计者选择了最简模型。而 ARM 架构则直接只提供两个级别（EL0 用户态、EL1 内核态）。
内核态与用户态的本质区别
两者的区别不在于代码本身，而在于 CPU 当前处于哪个特权级。同一段代码如果在 Ring 0 执行就是内核态，在 Ring 3 执行就是用户态。
| 对比维度 | 用户态 (Ring 3) | 内核态 (Ring 0) |
|---|---|---|
| 可执行指令 | 安全指令子集 | 所有指令（含特权指令） |
| 内存访问 | 仅限自己的虚拟地址空间 | 可访问所有物理内存和所有进程的地址空间 |
| 硬件访问 | 不能直接操作 I/O 端口 | 可直接操作所有硬件 |
| 失败后果 | 进程崩溃（Segfault） | 系统崩溃（Kernel Panic） |
| 切换开销 | 无（正常运行） | 500~1500 CPU 周期 / 次切换 |
特权指令示例
以下操作只能在内核态执行：
- I/O 操作：
in/out指令，直接读写硬件端口 - 修改页表：操控 CR3 寄存器，改变虚拟内存映射
- 关闭中断：
cli指令，阻止 CPU 响应外部中断 - 调整特权级：修改 CS 寄存器中的 CPL（Current Privilege Level）
如果用户态程序试图执行特权指令，CPU 会立刻触发一个保护异常（General Protection Fault, #GP），操作系统收到后通常会终止该进程。
用户态 → 内核态的切换机制
切换的本质是 CPU 特权级从 Ring 3 提升到 Ring 0。有三种触发方式：
1. 系统调用（主动触发）
应用程序需要内核服务时，通过系统调用主动发起。这是最常见的切换方式。
应用程序 (Ring 3) 内核 (Ring 0)
│ │
│ 1. 将系统调用号放入 eax 寄存器 │
│ 2. 将参数放入 ebx, ecx 等寄存器 │
│ 3. 执行 syscall / int 0x80 指令 │
│ ─────────────────────────────────▶ │
│ │ 4. CPU 自动：
│ │ - 保存用户态 rsp, rip
│ │ - 切换到内核栈
│ │ - 跳转到系统调用入口
│ │ 5. 根据调用号查表执行
│ │ 6. 执行完毕
│ ◀───────────────────────────────── │
│ 7. sysret / iret 指令返回 │
│ 恢复用户态上下文 │
x86-64 上的两种系统调用方式：
| 方式 | 指令 | 性能 | 说明 |
|---|---|---|---|
| 传统方式 | int 0x80 |
慢 | 通过软中断触发，需要走完整的中断处理流程 |
| 快速方式 | syscall / sysenter |
快 | 专用指令，跳过中断描述符表查找，直接进入内核 |
现代 Linux 使用 syscall 指令（64 位）和 sysenter（32 位）来提升系统调用性能。
2. 异常（被动触发 — 同步）
程序执行过程中发生错误或特殊条件时，CPU 自动触发异常：
| 异常类型 | 触发原因 | 内核处理方式 |
|---|---|---|
| 缺页异常 (Page Fault) | 访问未映射的虚拟内存页 | 分配物理页并建立映射 |
| 除零异常 | 执行除以零的运算 | 向进程发送 SIGFPE 信号 |
| 段错误 (Segfault) | 访问非法内存地址 | 向进程发送 SIGSEGV 信号 |
| 断点异常 | 执行到断点指令 (int 3) | 通知调试器 |
缺页异常是最「有用」的异常——虚拟内存机制正是利用缺页异常来实现按需分页（Demand Paging）：程序启动时不加载所有页面到内存，只有访问到某一页时才通过缺页异常触发加载。
3. 硬件中断（被动触发 — 异步）
外部设备完成操作或需要 CPU 注意时，通过中断控制器向 CPU 发送电信号：
键盘按下按键 ──▶ 中断控制器 ──▶ CPU 中断引脚
│
▼
CPU 暂停当前任务
保存上下文
切换到内核态
执行中断处理程序
恢复上下文
继续用户态任务
常见的硬件中断：
- 时钟中断：定时器每隔固定间隔（如 1ms / 4ms）触发，用于进程调度
- I/O 中断：磁盘读取完成、网卡收到数据包
- 键盘中断：用户按下按键
切换的性能开销
每次用户态 ↔ 内核态的切换，需要完成以下工作：
┌──────────────────────────────────────┐
│ 1. 保存用户态寄存器到内核栈 │ ~100 cycles
│ 2. 切换到内核栈（修改 RSP） │ ~10 cycles
│ 3. 执行安全检查 │ ~50 cycles
│ 4. 执行内核代码 │ 视具体操作
│ 5. 恢复用户态寄存器 │ ~100 cycles
│ 6. 切换回用户栈 │ ~10 cycles
│ 7. 刷新 TLB / 流水线 │ ~200 cycles
├──────────────────────────────────────┤
│ 总开销约 500 ~ 1500 CPU cycles │
│ 在 3GHz CPU 上约 0.2 ~ 0.5 微秒 │
└──────────────────────────────────────┘
虽然单次切换很快，但在高频场景下（如每秒上万次网络 I/O），切换开销会成为性能瓶颈。这也是为什么 Linux 引入了 epoll、io_uring 等机制来减少系统调用次数。
vDSO：不进内核的「系统调用」
Linux 提供了 vDSO（virtual Dynamic Shared Object） 机制，将一些只读的内核数据映射到用户空间，让某些「系统调用」可以在用户态完成，无需切换：
| 调用 | 传统方式 | vDSO 方式 |
|---|---|---|
gettimeofday() |
进入内核读取时钟 | 直接读用户态映射的页 |
clock_gettime() |
进入内核读取时钟 | 直接读用户态映射的页 |
getcpu() |
进入内核查询 CPU 号 | 直接读用户态映射的页 |
这些调用的共同特点是只读取数据、不修改系统状态，所以可以安全地在用户态完成。
生产高频题
用户态和内核态的区别是什么？
核心回答四点：(1) 权限不同——内核态可执行所有指令、访问所有内存；(2) 保护机制——用户态不能直接操作硬件，防止普通程序破坏系统；(3) 切换方式——通过系统调用、异常、中断三种方式触发；(4) 性能开销——每次切换需保存/恢复上下文，约 500~1500 CPU 周期。
为什么需要区分用户态和内核态？
安全隔离。如果所有程序都在内核态运行，任何一个 Bug 都可能导致整个系统崩溃。通过特权级划分，即使应用程序出错（Segfault），操作系统内核也不会受影响，只需杀掉出错的进程即可。
系统调用的完整过程？
- 应用程序将系统调用号和参数放入约定寄存器
- 执行
syscall指令（x86-64）触发特权级切换 - CPU 自动保存用户态上下文，切换到内核栈
- 内核根据调用号在系统调用表中查找对应处理函数
- 执行内核函数，完成后将结果放入
rax寄存器 - 执行
sysret指令返回用户态，恢复上下文