2、系统调用：系统调用流程、参数传递、返回值处理、性能分析

系统调用，说白了就是用户态程序请求内核帮忙干活的唯一通道。你想想看，用户态不能直接操作硬件、不能直接读写文件、不能直接分配内存——这些特权操作都被内核牢牢攥在手里。那用户程序怎么办？只能通过系统调用这个“大门”进去找内核帮忙。

我个人习惯把系统调用比作“用户态和内核态之间的一个函数调用”。但注意，它比普通函数调用要重得多。为什么？因为每次系统调用都要经历一次用户态到内核态的切换，这个切换本身就有不小的开销。

2.1 系统调用的完整流程

一个系统调用从用户程序发起，到内核处理完毕返回，大致经历这么几步：

1. 用户程序调用库函数（比如 read()、write()）
2. 库函数封装：glibc 把参数准备好，触发软中断或使用 syscall 指令
3. CPU 切换到内核态：保存用户态上下文，跳转到内核入口
4. 内核系统调用处理程序：根据系统调用号找到对应的内核函数
5. 执行内核函数：完成实际工作（如读写文件、分配内存）
6. 返回用户态：恢复上下文，把结果带回用户程序

嗯，这里要注意：第3步的“切换”是整个流程中最耗时的部分。我曾在一次性能调优中遇到过，一个高频调用的系统调用，光切换开销就占了总时间的 40%。

2.2 参数传递：怎么把数据带进内核？

系统调用的参数传递和普通函数调用不太一样。普通函数用栈传参，但系统调用不行——因为栈在用户态，内核不能直接信任用户栈的数据。

那怎么办？x86-64 架构下，参数通过寄存器传递。具体来说：

• 系统调用号：放在 rax 寄存器
• 参数 1-6：依次放在 rdi、rsi、rdx、r10、r8、r9
• 返回值：内核处理完后，结果放在 rax 中返回

举个例子，看看 read(fd, buf, count) 这个系统调用在底层是怎么传参的：

; 用户态 glibc 封装的汇编代码（简化）
mov    $0, %rax        ; 系统调用号：read 是 0
mov    $3, %rdi        ; 参数1：文件描述符 fd=3
mov    $buf, %rsi      ; 参数2：缓冲区地址
mov    $1024, %rdx     ; 参数3：读取字节数
syscall                ; 触发系统调用
; 返回值在 rax 中

2.3 返回值处理：成功还是失败？

系统调用的返回值处理有个经典套路。内核函数执行完后，把结果放在 rax 寄存器返回。但怎么区分成功和失败呢？

Linux 内核的约定是：

• 返回值 >= 0：表示成功，数值就是实际结果（比如 read 返回实际读取的字节数）
• 返回值 < 0：表示失败，绝对值就是错误码（比如 -EINVAL 表示参数无效）

但用户程序看到的不是这样。glibc 做了封装：如果内核返回负数，glibc 会把这个值取反后设置到 errno 全局变量中，然后返回 -1 给用户程序。所以用户程序通常这样写：

ssize_t ret = read(fd, buf, sizeof(buf));
if (ret == -1) {
    // 出错啦！具体错误在 errno 中
    perror("read failed");
    return -1;
}
// 正常处理 ret 字节的数据

while ((ret = read(fd, buf, len)) == -1 && errno == EINTR)
    ; // 被信号中断，重试
if (ret == -1) {
    // 真正的错误处理
}

2.4 性能分析：系统调用到底有多慢？

系统调用的性能开销，是每个做高性能开发的工程师都必须面对的课题。我做过一些基准测试，数据如下：

看到了吗？一个空系统调用比普通函数调用慢了两个数量级。这 100-200 纳秒的开销主要花在哪里了？

• 上下文切换：保存用户态寄存器、加载内核态寄存器
• TLB 刷新：切换地址空间可能导致 TLB 失效
• 权限检查：内核要验证用户传进来的参数是否合法
• 返回路径：从内核态切回用户态，恢复上下文

嗯，这里有个有意思的点：现代 CPU 的 syscall 指令比传统的 int 0x80 软中断快了不少。我测试过，同样的系统调用，用 syscall 比 int 0x80 快了大约 30%。

说白了，系统调用是用户态和内核态之间的“桥梁”，但这座桥的通行费不便宜。设计高性能程序时，要时刻想着：能不能少过几次桥？能不能一次多带点东西过桥？

公众号:蓝海资料掘金营，微信deep3321