系统调用为什么昂贵

系统调用的过程

系统有些高特权的操作，比如访问 IO 设备、修改内核状态、修改其他程序，在rings模型下，只有 ring 0 才能做得到。用户程序（通常运行在 ring 3）在自己的地址空间里面，是没有办法看到这些资源，也就无法修改它们。这时候用户程序就需要 request service，发出软（件）中断，让程序 trapped 进内核态（在传统 x86 32 位系统上通过 int 0x80 指令，在 x86-64 系统上则通过专用的 syscall 指令）。这不仅仅是进程的状态转换，也是处理器特权级别的转换（mode switch）。此时控制权已经交给内核了，内核可以在自己的内核地址空间里面，使用高特权操作，特权操作做完了以后，控制权才交回给用户程序。这个过程就称为 syscall。x86 虽然有四层 ring，但通常只使用了 0 和 3 两层 ring。

此处输入图片的描述

系统通常提供 API 或者 lib 来提供 syscall 的能力。比如在 Unix-Like 系统里，就是 glibc。lib 提供的函数，通常被称为 Wrapper Function。

系统调用的代价在哪里

系统调用的代价可以从两个层面来理解：模式切换（mode switch） 和可能触发的 上下文切换（context switch）。这两者经常被混淆，但它们的开销量级完全不同。

模式切换的微观代价

每次系统调用发生时，CPU 需要从用户态（ring 3）切换到内核态（ring 0）。这个过程中发生了一系列精密的硬件操作：

寄存器保存与恢复：CPU 必须保存用户态的寄存器状态（通用寄存器、程序计数器、栈指针、EFLAGS/RFLAGS 等），加载内核态的执行环境（切换到内核栈、加载内核的段描述符等）。系统调用执行完毕后，再恢复用户态的寄存器状态。即使不发生进程切换，这种模式切换本身也有固定开销——在现代 x86-64 处理器上，一次 syscall/sysret 指令对的裸开销大约在 50-100 个时钟周期。
TLB 的部分失效：TLB（Translation Lookaside Buffer）是 CPU 中缓存虚拟地址到物理地址映射的高速缓存。进入内核态后，CPU 需要访问内核的页表映射。虽然 Linux 使用高半区内核映射（内核地址空间映射在每个进程的高地址区域），避免了完整的 TLB flush，但内核代码路径上的 TLB miss 仍然不可避免。更严重的是，为了防御 Meltdown 等侧信道攻击，现代 Linux 内核启用了 KPTI（Kernel Page Table Isolation），在用户态和内核态之间使用不同的页表，这意味着每次模式切换都会导致大量 TLB 条目失效，代价显著增加。
CPU 缓存污染（Cache Pollution）：内核代码和数据会占用 L1/L2/L3 缓存行，挤出用户态的热点数据。返回用户态后，被挤出的缓存行需要重新从内存加载，每次 cache miss 的代价在 100-300 个时钟周期（取决于是 L2 miss 还是 L3 miss）。对于缓存敏感的热路径代码，这种间接代价可能远超模式切换本身的直接代价。
分支预测器污染：CPU 的分支预测器（Branch Predictor）维护着一张分支历史表。进入内核后执行的分支指令会污染这张表，导致返回用户态后的分支预测准确率下降，引发流水线停顿（pipeline stall）。

`int 0x80` vs `syscall` 指令

在 x86 架构的演进中，系统调用的入口机制经历了显著的优化。传统的 int 0x80 是一条通用的软中断指令，它需要经过完整的中断描述符表（IDT）查找、特权级检查、栈切换等流程，开销较大。x86-64 引入的 syscall/sysret 指令对是专门为系统调用设计的快速路径——它们通过 MSR（Model Specific Register）寄存器预先配置好内核入口点和段选择子，跳过了 IDT 查找，将模式切换的指令级开销从数百个时钟周期降低到约 50-100 个时钟周期。在 32 位 x86 上，Intel 还提供了 sysenter/sysexit 指令对作为类似的快速路径。

阻塞型系统调用与上下文切换

有些系统调用会涉及 IO 操作。阻塞型系统调用（如 read()、write()）在数据未就绪时，会导致当前进程被操作系统调度器挂起（放入等待队列），此时 CPU 会被调度给其他进程使用。这就触发了完整的进程上下文切换，其代价远超单纯的模式切换：

需要保存和恢复完整的进程状态（包括所有寄存器、FPU/SSE/AVX 状态、信号掩码等）
需要切换页表基址寄存器（CR3），导致 TLB 全量失效
调度器本身的运行也需要消耗 CPU 时间
新进程的工作集（working set）需要重新加载到缓存中，产生大量 cache miss

一次完整的上下文切换的代价通常在数千到数万个时钟周期，比单纯的模式切换高出 1-2 个数量级。

而某些场景下的忙等待（busy-wait / spin-wait）则会占用 CPU 时间片而不出让 CPU，虽然避免了上下文切换的开销，但造成了 CPU 资源浪费。这也是为什么 spinlock 只适用于临界区极短的场景。

vDSO：绕过系统调用的优化

Linux 内核提供了一种巧妙的优化机制——vDSO（virtual Dynamic Shared Object）。对于某些只需要读取内核数据而不需要修改内核状态的系统调用（如 gettimeofday()、clock_gettime()），内核会将相关数据映射到用户态可读的共享内存页中，并在 vDSO 中提供用户态的实现函数。这样，调用这些函数时完全不需要陷入内核态，直接在用户态完成，开销从数百个时钟周期降低到几十个时钟周期。

这是一个值得推广的设计模式：如果一个操作只需要读取共享状态而不需要修改它，那么可以通过共享内存 + 用户态读取来避免跨越保护边界的开销。

对 Java 程序员的启示

理解系统调用的代价对 Java 程序员同样重要。JVM 本身是一个用户态进程，但 Java 程序中的许多操作最终会转化为系统调用：

IO 操作：FileInputStream.read()、Socket.getInputStream().read() 等最终都会调用 read() 系统调用
线程操作：Thread.start() 调用 clone()，synchronized 在竞争时调用 futex()
内存分配：当 JVM 堆需要扩展时，会调用 mmap() 或 brk()
时间获取：System.currentTimeMillis() 调用 gettimeofday()（不过在 Linux 上通过 vDSO 优化，代价很小）

这也解释了为什么 Java NIO 的 epoll 模型比传统的阻塞 IO 模型性能更好——它通过一次 epoll_wait() 系统调用就能监控大量文件描述符的就绪状态，大幅减少了系统调用的次数。同样，这也是为什么 JVM 的 Unsafe.getInt() 等操作被设计为 intrinsic 方法——它们直接在用户态完成内存访问，完全避免了系统调用。