操作系统基石：进程与线程的区别、用户态与内核态切换、上下文切换的开销
各位同学，咱们今天聊点硬核的。做高并发，说白了就是在跟操作系统打交道。你写的代码再漂亮，最后都得交给操作系统去调度。我见过太多人，并发上不去就盲目加机器，结果发现瓶颈根本不在业务代码，而是操作系统那层已经扛不住了。
这一节，咱们把三个最基础也最关键的概念掰开揉碎：进程与线程、用户态与内核态、上下文切换。搞懂它们，你才算真正入了高并发的门。
2.1 进程与线程：到底差在哪？
先问个问题：进程和线程，你脑子里第一反应是什么？
很多人会说“进程是资源分配的最小单位，线程是CPU调度的最小单位”。这话没错，但太抽象了。我换个说法：进程就像一家公司，线程就是公司里的员工。
- 进程：有自己的独立办公区（内存空间）、自己的营业执照（PID）、自己的财务账本（文件描述符）。公司之间不能随便串门，想交换数据得走正规渠道（IPC）。
- 线程：共享公司的办公区、财务、资源。大家在一个大平层里干活，交流起来方便（共享内存），但要是抢同一台打印机（临界资源），就得排队（锁）。
我在项目中遇到过一件事：一个老系统，每次请求来了就fork一个新进程去处理。并发一高，机器直接卡死。为什么？因为fork进程的开销太大了——复制页表、复制文件描述符表、复制信号处理函数……一套流程走下来，光创建就得好几毫秒。后来改成线程池，吞吐量直接翻了三倍。
核心区别速览
| 对比维度 | 进程 | 线程 |
|---|---|---|
| 地址空间 | 独立，互不干扰 | 共享同一进程的地址空间 |
| 资源开销 | 大（创建、切换、销毁都重） | 小（轻量级） |
| 通信方式 | IPC（管道、消息队列、共享内存等） | 直接读写共享变量 |
| 健壮性 | 一个进程挂了不影响其他进程 | 一个线程挂了，整个进程可能崩溃 |
| 适用场景 | 强隔离、多任务、稳定性要求高 | 高并发、频繁交互、计算密集型 |
我的习惯：做高并发服务，首选线程模型。但如果需要跑第三方插件或者不信任的代码，我会用进程隔离，防止一个插件把整个服务拖垮。曾经有个支付网关项目，就是因为一个第三方SDK的内存泄漏，导致所有线程一起遭殃——从那以后，我对进程隔离有了执念。
2.2 用户态与内核态：那道看不见的墙
你想想看，为什么操作系统要把运行模式分成用户态和内核态？
说白了，就是为了保护。内核态拥有最高权限，能访问所有硬件、所有内存。用户态呢？只能在自己的小圈子里玩。你要是让普通程序随便碰硬件，那系统早乱套了。
举个例子：你的程序想从磁盘读个文件。在用户态，你只能调用read()这个库函数。然后呢？
- 库函数触发一个系统调用（syscall）。
- CPU从用户态切换到内核态。
- 内核去操作磁盘控制器，把数据读到内核缓冲区。
- 再把数据从内核缓冲区拷贝到你的用户态缓冲区。
- 最后切换回用户态，
read()返回。
这一进一出，就是一次用户态与内核态的切换。每次切换，CPU要保存用户态的寄存器、栈指针，加载内核态的寄存器、栈指针，还要查权限表……开销不小。
避坑指南：我曾经优化过一个网关程序，发现CPU使用率奇高，但业务吞吐量上不去。用perf一分析，好家伙，gettimeofday()每秒调了几十万次！每次调用都是一次系统调用，一次用户态/内核态切换。后来改成用clock_gettime()配合vDSO（内核映射到用户态的只读数据），切换次数直接降为零。记住：减少不必要的系统调用，就是减少用户态/内核态切换。
为什么会这样？因为系统调用是用户态进入内核态的唯一合法途径。每次系统调用，CPU都要执行一条特殊的指令（比如x86上的syscall或int 0x80），触发模式切换。
我建议你记住这个数字：一次用户态/内核态切换，大约需要50-100纳秒。看起来不多对吧？但如果你每秒做100万次系统调用，光切换就浪费了50-100毫秒的CPU时间。在高并发场景下，这就是灾难。
2.3 上下文切换：看不见的性能杀手
上下文切换，就是CPU从一个任务切换到另一个任务的过程。无论是进程切换还是线程切换，都得走这套流程。
具体干点啥？
- 保存当前任务的上下文（寄存器、程序计数器、栈指针）。
- 加载下一个任务的上下文。
- 刷新TLB（页表缓存）。
- 可能还要处理缓存失效。
嗯，这里要注意：线程切换比进程切换轻。因为线程共享地址空间，切换时不需要换页表，TLB也不用全刷。但进程切换呢？页表一换，TLB基本就废了，后续的内存访问全是缓存未命中，性能直接跳水。
上下文切换开销对比
| 切换类型 | 典型耗时 | 主要开销来源 |
|---|---|---|
| 同一进程内线程切换 | ~1-3微秒 | 寄存器保存/恢复 |
| 不同进程间切换 | ~3-10微秒 | 页表切换 + TLB刷新 + 缓存失效 |
| 系统调用（用户态↔内核态） | ~50-100纳秒 | 模式切换 + 权限检查 |
你想想看，如果一台机器上有1000个线程在疯狂争抢CPU，每秒上下文切换次数轻松破百万。每次切换1-3微秒，光切换就占了几十毫秒的CPU时间。更可怕的是，频繁切换会导致CPU缓存反复失效，内存访问延迟暴增。
我记得有一次线上事故，一个Java服务CPU飙到100%，但QPS反而下降了。查了半天，发现是线程池开得太大，几千个线程在互相抢CPU，大部分时间都花在上下文切换上了。把线程池大小调成CPU核心数的两倍，问题立刻解决。
我的建议：
- 线程数不是越多越好。理想情况下，线程数 ≈ CPU核心数 × (1 + 等待时间/计算时间)。IO密集型可以多开，计算密集型少开。
- 能用协程就别用线程。协程的切换完全在用户态完成，不需要内核参与，开销可以忽略不计。
- 减少锁竞争。锁会导致线程阻塞、唤醒，引发额外的上下文切换。
2.4 一张图看懂：进程、线程、切换的关系
下面这张图，把咱们今天讲的核心逻辑串起来了。你仔细看看，每个节点都对应一个知识点。
2.5 总结：高并发视角下的操作系统
咱们今天聊了三个基石，我帮你串一下：
- 进程 vs 线程：选线程，轻量、共享、高效。但要注意线程安全。
- 用户态 vs 内核态：系统调用是必经之路，能少就少。能用用户态解决的问题，别麻烦内核。
- 上下文切换：看不见的杀手。控制线程数量、减少锁竞争、用协程替代线程，都是有效的优化手段。