第一章：系统编程基础——进程与线程、用户态与内核态、上下文切换开销、系统调用原理
各位同学，咱们今天聊聊系统编程的根基。说实话，我见过太多工程师，框架用得飞起，但一问到进程和线程到底怎么切换的，就卡壳了。这不行。底层的东西，你越早吃透，后面调优的时候就越有底气。
1.1 进程与线程：到底有什么区别？
先说说进程。进程，说白了就是「正在运行的程序实例」。你双击一个浏览器，操作系统就给它分配一块独立的内存空间、文件句柄、寄存器状态——这就是一个进程。每个进程有自己的地址空间，互不干扰。我当年刚入行时，以为进程就是程序，后来才明白，程序是死的，进程是活的。
线程呢？线程是进程里的「执行单元」。一个进程可以包含多个线程，它们共享进程的内存空间。举个例子：你打开一个文本编辑器，主线程负责界面响应，后台线程负责自动保存。这就是多线程协作。
核心区别一句话：进程是资源分配的最小单位，线程是CPU调度的最小单位。
我习惯用一个比喻来理解：进程就像一家公司，有自己的办公楼（内存）、财务（文件句柄）。线程就是公司里的员工，共享办公区，但每个人干自己的活。公司倒闭（进程终止），所有员工都得走人。
1.2 用户态与内核态：为什么要有两套模式？
这个问题，我面试时必问。很多人答不上来。其实很简单——为了安全。
操作系统把CPU的运行模式分成两种：
- 用户态：应用程序跑的地方。权限受限，不能直接操作硬件，不能访问内核数据结构。
- 内核态：操作系统内核跑的地方。拥有最高权限，可以访问所有内存、控制硬件、管理系统资源。
为什么要这么分？你想想看，如果每个应用程序都能直接写硬盘、改内存，那一个bug就能让整个系统崩溃。我曾在项目中遇到过一个问题：一个第三方库在用户态直接尝试访问硬件寄存器，结果触发段错误，整个进程挂了。幸好是用户态，系统没崩。要是内核态，那就得重启服务器了。
我的经验：用户态和内核态的切换，是系统性能的关键瓶颈之一。每次切换都要保存和恢复大量寄存器状态，开销不小。后面我们会详细讲怎么减少这种切换。
1.3 上下文切换开销：看不见的性能杀手
上下文切换，就是CPU从一个进程/线程切换到另一个。听起来简单，但开销比你想象的大得多。
一次完整的上下文切换包括：
- 保存当前进程的寄存器状态（PC、SP、通用寄存器等）
- 更新进程控制块（PCB）
- 选择下一个要运行的进程
- 恢复新进程的寄存器状态
- 刷新TLB（页表缓存）
我做过一个性能测试：在一台2.6GHz的机器上，一次线程上下文切换大约需要1-3微秒。听起来不多？但如果你的系统每秒切换10万次，那就是100-300毫秒的纯开销。这还没算缓存失效带来的惩罚。
| 操作类型 | 大致耗时 | 相对比例 |
|---|---|---|
| CPU周期 | 0.4 ns | 1x |
| L1缓存命中 | 0.5 ns | ~1x |
| L2缓存命中 | 7 ns | ~17x |
| 主存访问 | 100 ns | ~250x |
| 上下文切换 | 1-3 μs | ~2500-7500x |
看到没？一次上下文切换，相当于几千次CPU周期。我曾经优化过一个高并发网关，发现CPU大量时间花在上下文切换上。后来通过调整线程池大小、使用协程，把切换次数降了80%，吞吐量直接翻倍。
避坑指南：不要盲目创建大量线程。我曾经接手过一个项目，为了「提高并发」，创建了500个线程。结果CPU全在切换，实际干活的时间不到10%。记住：线程数 = CPU核心数 + 1 到 2 个I/O线程，就够了。
1.4 系统调用原理：用户态怎么请求内核帮忙？
系统调用，是用户态程序请求内核服务的唯一途径。比如你写个read()函数，背后就是一次系统调用。
流程是这样的：
- 应用程序调用库函数（如glibc的
read()） - 库函数将参数放入寄存器，触发软中断（如x86上的
int 0x80或syscall指令） - CPU切换到内核态，根据系统调用号找到对应的内核函数
- 内核执行操作（如从磁盘读取数据）
- 结果返回用户态，继续执行
嗯，这里要注意：每次系统调用都涉及用户态到内核态的切换，这是有成本的。我习惯用strace工具来查看程序到底做了多少次系统调用。有一次我发现一个日志库，每写一行日志就调用一次write()，导致性能极差。改成批量写入后，性能提升了5倍。
核心要点：系统调用不是免费的。减少不必要的系统调用，是性能优化的基本功。
知识体系总览
下面这张图，是我自己总结的本章知识结构。你可以把它当作一张地图，随时回来对照。
好了，这一章的内容就到这里。记住：进程和线程的区别、用户态和内核态的分工、上下文切换的成本、系统调用的机制——这四个点，是系统编程的基石。后面讲多线程调优、锁优化、内存模型，全都建立在这些概念之上。
可可精品资料库