操作系统 on 纪伟的个人博客

操作系统学习笔记（五）：内存管理

Tue, 12 May 2026 10:00:00 +0800

写在前面

本文讲操作系统的内存管理：虚拟内存、页表、TLB、malloc、内存池。理解这些才能明白为什么"内存比磁盘快万倍"、为什么程序要少分配、GC 为什么会影响性能。

一、虚拟内存

1.1 为什么需要虚拟内存

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


没有虚拟内存（早期）：
 程序直接操作物理内存
 问题：
 ✗ 进程间互相踩内存（A 写错地址破坏 B）
 ✗ 内存不够用（物理内存有限）
 ✗ 程序地址不固定（换台机器/换次运行地址就变）

有虚拟内存：
 每个进程有自己独立的、连续的虚拟地址空间
 CPU 看到的是虚拟地址，由 MMU 翻译成物理地址

1
2
3
4
5
6


虚拟内存的好处：
 ✓ 进程隔离（每个进程独立地址空间，互不干扰）
 ✓ 内存"变多"（虚拟空间可大于物理内存，用磁盘做扩展）
 ✓ 地址固定（程序总是从固定地址加载，不用关心物理位置）
 ✓ 按需分配（用到才分配物理页，懒加载）
 ✓ 共享内存（多个进程的虚拟页映射到同一物理页）

1.2 地址翻译

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


程序用虚拟地址 → MMU（内存管理单元）翻译 → 物理地址

 虚拟地址空间（64位，实际用 48 位 = 256TB）
 ┌────────────────┐
 │ 用户空间（高地址）│
 │ 栈 ↓ │
 │ 共享库 │
 │ 堆 ↑ │
 │ 数据段 │
 │ 代码段 │
 └────────────────┘
 ┌────────────────┐
 │ 内核空间 │
 └────────────────┘

 每个进程都觉得自己独占这整个空间
 实际物理内存由 OS 分配页

二、分页与页表

2.1 分页机制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


虚拟内存按固定大小切成「页」（通常 4KB）
物理内存也切成「页框」（4KB）

虚拟页 → 映射到 → 物理页框
不连续：虚拟页 0/1/2 可映射到物理页框 5/100/3

 虚拟页 ┌───┬───┬───┬───┐
 │ 0 │ 1 │ 2 │...│
 └─┬─┴─┬─┴───┴───┘
 │ │
 物理页框 ┌─▼─┬─▼─┬───┬───┐
 │ 5 │100│...│ 3 │ （页表记录这个映射）
 └───┴───┴───┴───┘

2.2 页表

1
2
3
4
5
6
7
8
9


页表 = 记录「虚拟页 → 物理页」映射的数据结构

 每个进程一个页表
 多级页表（x86-64 通常 4 级）：
 虚拟地址拆成 5 段，逐级查表

 为什么多级：节省页表内存
 单级：256TB/4KB = 640亿项，每进程页表就几百GB，不可能
 多级：只存用到的部分，按需创建

2.3 TLB（Translation Lookaside Buffer）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


问题：每次地址翻译要查多级页表（多次内存访问），太慢

TLB = CPU 内的页表缓存
 缓存最近用过的「虚拟页→物理页」映射
 命中 TLB → 一次拿到物理地址（极快）

 TLB 很小（几百项），但命中率极高（因为局部性）

 这就是为什么上下文切换贵：
 切换进程 → 页表换了 → TLB 失效 → 短期内翻译变慢

三、缺页中断

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


访问一个虚拟地址时：
 1. 查页表，发现该页不在物理内存（未分配/被换出到磁盘）
 2. 触发「缺页中断」（Page Fault）
 3. OS 接管：
 - 分配新的物理页（首次访问）
 - 或从磁盘换回数据（之前被换出）
 4. 更新页表，恢复执行

 缺页中断是慢的（涉及磁盘 I/O）
 频繁缺页 = 抖动（thrashing），性能暴跌

四、内存分配（malloc 的真相）

4.1 用户态分配

1
2


// C 的 malloc / C++ 的 new / 语言的分配
void *p = malloc(100); // 申请 100 字节

1
2
3
4
5
6
7
8
9


malloc 的实现（如 glibc ptmalloc）：
 小块（< 128KB）：用 brk 扩展堆
 brk 指针上移，堆增长
 free 后内存不归还 OS，留作复用
 大块（≥ 128KB）：用 mmap 直接映射
 独立区域，free 后归还 OS

 malloc 本身是用户态内存分配器
 真正向 OS 要内存用系统调用（brk/mmap）

4.2 内存碎片

1
2
3
4
5


内部碎片：申请 100 字节，分配器给了 128 字节（对齐），浪费 28
外部碎片：频繁分配/释放后，空闲内存碎成小块，无法满足大请求

 即使总空闲内存够，也可能因为碎片导致分配失败
 分配器（jemalloc/tcmalloc）的一大工作就是对抗碎片

4.3 高性能内存分配器

1
2
3
4
5
6
7


glibc ptmalloc — 通用，但有锁竞争、碎片问题
jemalloc — FreeBSD/Redis/Facebook 用，抗碎片、多线程好
tcmalloc — Google，线程缓存，多线程高性能
mimalloc — 微软，现代、快

 高性能程序（Redis、.NET runtime、Go runtime）都有自己的分配器
 共同优化：线程本地缓存（避免锁）、按大小类（对抗碎片）、多级分配

五、内存池

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


为什么要有内存池：
 malloc/free 频繁调用有开销（系统调用、锁、碎片）
 高频分配场景（如每秒处理万级请求）开销大

内存池思路：
 预先一次性申请大块内存
 自己管理分配/回收
 避免反复 malloc/free

 .NET 的 GC 堆、Nginx 的 pool、对象的 ArrayPool 都是内存池思想

 Nginx pool（见 Nginx 深入原理篇）：
 每个请求一个 pool，请求中所有分配从 pool 切
 请求结束，pool 整体释放 → 极快，无碎片，无泄漏

六、页面置换

1
2
3
4
5
6
7
8
9


物理内存不够时，OS 把不常用的页换到磁盘（swap）
换出哪页？用置换算法：

 LRU（最近最少使用）— 实际常近似实现
 LFU（最不经常使用）
 Clock（时钟算法，LRU 的近似）

 抖动：频繁换页，磁盘 I/O 暴涨，性能崩溃
 生产环境通常关闭 swap（或设低），避免抖动

七、为什么这些影响程序性能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


1. 分配不是免费的
 每次 malloc/new → 分配器工作 → 可能让 GC 回收 → 缺页
 所以"减少分配"是性能优化的核心（Span、ArrayPool、对象池）

2. 访问局部性影响 TLB/缓存命中
 顺序访问数组 → 缓存命中好
 随机访问链表/指针追逐 → 缓存失效，慢
 所以数组/连续内存比链表快（缓存友好）

3. GC 与内存管理
 GC 堆 = 内存池的一种
 分配越多 → GC 越频繁 → 暂停越久
 减少分配 = 减少 GC = 提升性能

4. 上下文切换贵
 TLB 失效是切换开销的重要部分
 所以协程（不切进程/线程，TLB 不失效）比线程快

八、小结

虚拟内存：每进程独立地址空间，隔离+按需分配+可大于物理内存
分页+页表：4KB 页，多级页表映射虚拟→物理
TLB：页表缓存，命中则快；切换进程失效，所以上下文切换贵
缺页中断：页不在内存时触发，涉及磁盘，慢
malloc：小块用 brk（堆），大块用 mmap；碎片是分配器的头号敌人
内存池：预分配+自管理，避免反复 malloc（Nginx pool、GC 堆、ArrayPool）
对性能的影响：分配有成本、缓存局部性、GC、上下文切换

核心认知：内存不是无限免费的——分配、翻译、回收都有成本。高性能编程的本质之一，就是理解这些成本并尽量减少。

系列总结

操作系统底层五篇完结：

I/O 模型：5 种模型，前 4 种同步、异步 I/O 才是真异步
进程线程协程：资源/调度单位，协程轻量适合高并发
Reactor/Proactor：I/O 模型如何变成网络框架（Nginx/Netty/Redis）
零拷贝：sendfile/mmap/splice 减少多余拷贝
内存管理：虚拟内存、页表、TLB、malloc、内存池

这些是 Nginx、Redis、Kafka、Kestrel 高性能的底层根基。理解了它们，再看任何中间件、框架的性能文章，都能看懂"为什么"。

操作系统学习笔记（四）：零拷贝技术

Mon, 11 May 2026 10:00:00 +0800

写在前面

本文讲零拷贝（Zero-Copy）——把数据从磁盘发到网络，能少拷贝几次就少几次。这是 Nginx 静态文件飞快、Kafka 高吞吐的关键技术之一。

一、传统读写的开销

场景：服务器从磁盘读一个文件，通过网络发给客户端。

1.1 传统方式

1
2
3
4


// 传统 4 步
char buf[4096];
read(fd, buf, 4096); // 磁盘 → 用户态
write(sock, buf, 4096); // 用户态 → 网络

看似两行，实际发生了4 次数据拷贝 + 4 次上下文切换：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


 内核空间 用户空间
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 磁盘 │──DMA──→│ 内核缓冲区 │──CPU拷贝─→│ 用户buf │ read()
 └─────────┘ └──────────┘ └──────────┘
 ↑ │
 （步骤1,2） CPU拷贝
 ↓
 ┌──────────┐ ┌──────────┐
 │ Socket │←─CPU拷贝─│ 用户buf │ write()
 │ 缓冲区 │ └──────────┘
 └─────┬────┘
 DMA
 ┌─────▼────┐
 │ 网卡 │
 └──────────┘
 （步骤3,4）

 4 次拷贝：
 1. 磁盘 → 内核缓冲区（DMA）
 2. 内核缓冲区 → 用户 buf（CPU） ← 多余！用户根本没处理数据
 3. 用户 buf → Socket 缓冲区（CPU） ← 多余！
 4. Socket 缓冲区 → 网卡（DMA）

 4 次上下文切换：read(2次) + write(2次)

1
2
3
4
5
6


问题：
 数据从磁盘到网卡，根本不需要经过用户空间
 但传统 read+write 强制数据绕道用户态
 白白多了 2 次 CPU 拷贝 + 2 次上下文切换

 零拷贝的目标：消除这 2 次多余的 CPU 拷贝

二、mmap + write（减少一次拷贝）

mmap 把内核缓冲区和用户空间映射到同一块内存，省去内核→用户的拷贝。

1
2
3


char *p = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0); // 映射
write(sock, p, size); // 直接从映射区写
munmap(p, size);

1
2
3
4
5
6
7
8


拷贝流程：
 磁盘 →(DMA)→ 内核缓冲区（= 用户映射区，共享）
 内核缓冲区 →(CPU)→ Socket 缓冲区 →(DMA)→ 网卡

 省了「内核缓冲区→用户buf」这次拷贝
 剩 3 次拷贝（2 DMA + 1 CPU），4 次上下文切换

 适合：用户需要读数据内容（如处理后再发）

三、sendfile（真正的零拷贝）

Linux 2.1 引入，专门为"文件→Socket"传输设计。数据全程不进用户空间。

1
2


#include <sys/sendfile.h>
sendfile(sock, fd, &offset, size); // 一步到位

1
2
3
4
5
6
7
8


拷贝流程（原始 sendfile）：
 磁盘 →(DMA)→ 内核缓冲区 →(CPU)→ Socket 缓冲区 →(DMA)→ 网卡

 数据不进用户态！
 2 次拷贝（2 DMA）+ 1 次 CPU 拷贝
 2 次上下文切换（一次系统调用）

 对比传统：4次拷贝+4次切换 → 3次拷贝+2次切换

SG-DMA 优化（Linux 2.4+，终极零拷贝）

如果网卡支持 SG-DMA（Scatter-Gather DMA），连那 1 次 CPU 拷贝都省了：

1
2
3
4
5
6
7


拷贝流程（SG-DMA）：
 磁盘 →(DMA)→ 内核缓冲区
 内核只把「缓冲区地址 + 长度」描述符发给 Socket 缓冲区
 网卡根据描述符直接从内核缓冲区 DMA → 网卡

 全程只有 2 次 DMA 拷贝，0 次 CPU 拷贝！
 这就是真正的"零拷贝"（CPU 零拷贝）

1
2


 Nginx 的 sendfile on; 就是开启这个
 静态文件传输极快的根本原因

四、splice（管道零拷贝）

sendfile 只能文件→Socket。splice 更通用，任意两个 fd 之间（通过管道）零拷贝。

1
2
3
4


int pipefd[2];
pipe(pipefd);
splice(fd, &offset, pipefd[1], NULL, size, SPLICE_F_MOVE); // 文件 → 管道
splice(pipefd[0], NULL, sock, NULL, size, SPLICE_F_MOVE); // 管道 → Socket

1
2


适合：两个非 Socket 的 fd 间传输（如文件→文件、管道中转）
本质：用内核管道缓冲区做中转，避免数据进用户态

五、对比总结

1
2
3
4
5
6
7


方式 CPU拷贝 DMA拷贝 上下文切换 数据进用户态
────────────────────────────────────────────────────────────────
传统 read+write 2 2 4 是
mmap + write 1 2 4 是（映射）
sendfile 1 2 2 否
sendfile + SG-DMA 0 2 2 否 ← 最优
splice 0 2 2 否

六、实际应用

6.1 Nginx

1
2
3
4
5
6


http {
 sendfile on; # 开启 sendfile 零拷贝
 tcp_nopush on; # 配合 sendfile，等数据攒够再发
}

# 静态文件传输直接走 sendfile，磁盘→网卡不进用户态

6.2 Kafka

1
2
3
4
5
6
7


Kafka 高吞吐的关键之一：消费者拉消息用 sendfile

 消息存在磁盘日志（顺序写，快）
 消费者拉取 → 直接 sendfile 从磁盘文件发到网络
 不经过 JVM 堆，无 GC 压力，无内存拷贝

 这让 Kafka 能轻松百万级 TPS

6.3 Java 的零拷贝 API

1
2
3
4
5


Java NIO：
 FileChannel.transferTo() → 底层就是 sendfile
 MappedByteBuffer → 底层是 mmap

 Kafka、Netty 都用这些实现零拷贝

七、.NET 的零拷贝

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


.NET 用 Stream 的 CopyToAsync 在内部尽量优化
 但不是直接对应 sendfile

ASP.NET Core 的静态文件中间件：
 用一些平台优化（如 Linux 下用 sendfile 语义）
 + Pipelines 减少分配

Span<T> / Memory<T>：
 不是网络零拷贝，但提供了"零拷贝切片"内存视图
 避免切片字符串/数组时的拷贝

八、小结

传统读写：4 次拷贝（2 CPU + 2 DMA）+ 4 次切换，数据多余绕道用户态
mmap：内核/用户共享内存，省 1 次 CPU 拷贝（适合需要读内容）
sendfile：文件→Socket 不进用户态，省拷贝 + 切换
sendfile + SG-DMA：CPU 零拷贝，只剩 2 次 DMA（最优）
splice：任意两 fd 间零拷贝（通过管道）
应用：Nginx sendfile、Kafka transferTo、Java FileChannel.transferTo

零拷贝 + I/O 多路复用 + Reactor = 高性能网络服务器三件套。下一篇讲内存管理（虚拟内存、页表、malloc）。

操作系统学习笔记（三）：Reactor 与 Proactor 模式

Sun, 10 May 2026 10:00:00 +0800

写在前面

上一篇讲了 I/O 模型（epoll、AIO）。但 epoll 只是底层机制，要变成一个能用的网络服务器，需要一套设计模式把"事件分发"和"业务处理"组织起来——这就是 Reactor 和 Proactor。Netty、Nginx、Redis、Kestrel 都基于这些模式。

一、Reactor 模式

1.1 核心思想

Reactor = 基于同步 I/O 多路复用的事件驱动模式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


核心组件：
 1. Reactor（事件分发器）
 用 epoll/select 监听所有 fd，事件就绪时分发给对应 Handler

 2. Acceptor（接收器）
 处理新连接（accept）

 3. Handler（处理器）
 处理具体连接的读写、业务

流程：
 Reactor 监听 → 新连接来了，Acceptor 接收 → 注册到 Reactor
 → 数据来了，Reactor 通知 Handler → Handler 读写+处理

1
2
3
4


关键特征（同步）：
 I/O 操作（read/write）还是由 Handler 同步执行
 Reactor 只负责"通知就绪"，不做实际 I/O
 本质是「事件来了 → 你自己去读」

1.2 三种 Reactor 实现

单 Reactor 单线程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


 一个线程，一个 Reactor 干所有事：
 accept、read、业务处理、write 全在一个线程

 ┌─────────────────┐
 │ Reactor（1线程） │
 │ accept + IO + 业务 │
 └─────────────────┘

 代表：Redis 6.0 之前

 优点：极简，无线程同步问题
 缺点：一个连接的慢操作卡死所有连接
 无法利用多核

单 Reactor 多线程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 Reactor（1线程）只负责 accept + 读写分发
 业务处理交给线程池

 ┌──────────┐ ┌──────────────┐
 │ Reactor │────→│ 业务线程池 │
 │ accept+IO │ │ 多线程处理 │
 └──────────┘ └──────────────┘

 优点：业务多线程，利用多核
 缺点：Reactor 单线程仍是瓶颈（所有 I/O 集中）
 Handler 和业务线程间要同步

主从 Reactor 多线程（最常用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


 MainReactor 专门 accept 新连接
 SubReactor（多个）处理已建立连接的读写
 业务可选交给线程池

 ┌────────────┐
 │ MainReactor │ accept
 └─────┬──────┘
 │ 新连接分发
 ┌─────▼──────┐ ┌──────────┐ ┌──────────┐
 │ SubReactor │ │SubReactor │ │SubReactor │ 各自 epoll 处理 IO
 └────────────┘ └──────────┘ └──────────┘

 代表：Netty、Nginx（主进程accept + worker处理）

 优点：充分利用多核，accept 和 IO 分离，吞吐高
 这是高性能服务器的标准架构

二、Nginx 的 Reactor 架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Nginx = 主从 Reactor 多进程版：

 Master 进程
 │ accept（但不处理，转交 worker）
 │
 Worker 进程 ×N（= CPU 核数）
 每个 Worker 自己的 epoll + Reactor
 独立处理连接的读写、业务

 特点：
 多进程（不是多线程）→ 无锁、崩溃隔离
 每个 Worker 一个 Reactor（单线程事件循环）
 用共享内存（不是锁）通信

三、Redis 的事件模型

1
2
3
4
5
6
7
8


Redis 6.0 之前：单 Reactor 单线程
 一个线程跑事件循环 + 命令执行
 为什么快：内存操作极快 + 无锁 + 无上下文切换

Redis 6.0+：单 Reactor + IO 多线程
 命令执行仍单线程（保证原子、无锁）
 网络 read/write 用多线程（IO 瓶颈在多核上并行）
 本质：IO 用 Reactor 多线程，业务仍串行

四、Proactor 模式

Proactor = 基于异步 I/O 的事件驱动模式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


核心区别（对比 Reactor）：

Reactor（同步）：
 事件就绪 → 通知 Handler → Handler 自己 read（同步拷贝）
 "数据来了，你自己读"

Proactor（异步）：
 发起异步 read → 内核读完+拷贝完 → 通知 Handler 处理
 "数据我已经读好了，你直接用"

Proactor 流程：
 1. 发起 aio_read（异步，立即返回）
 2. Handler 继续干别的
 3. 内核完成（等数据+拷贝）→ 通知
 4. Handler 拿到的数据已就绪，直接处理

1
2
3


关键特征（异步）：
 I/O 操作由内核完成，Handler 只处理就绪的数据
 本质是「我帮你读好了，告诉你」

五、Reactor vs Proactor

1
2
3
4
5
6
7
8


 Reactor Proactor
──────────────────────────────────────────────────────
I/O 模型 同步（epoll） 异步（IOCP/io_uring）
I/O 谁做 Handler 自己 内核做
通知时机 数据就绪 数据已拷贝完
实现复杂度 简单 复杂
OS 支持 Linux epoll 成熟 Windows IOCP 成熟 / Linux io_uring 新
代表 Nginx/Netty/Redis Windows IOCP、Boost.Asio

1
2
3
4
5
6
7


为什么主流还是 Reactor：
 Linux 的异步 I/O（AIO）长期不成熟
 io_uring（2019）才让 Linux 有了高性能异步 I/O
 epoll + Reactor 已足够高效，生态成熟
 Windows 用 Proactor（IOCP）

 趋势：io_uring 普及后，Linux 上的 Proactor 会越来越多

六、实际框架对应

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


框架/系统 模式 底层
──────────────────────────────────────────────────────
Nginx 主从 Reactor 多进程 epoll
Redis Reactor（IO 多线程） epoll
Netty（Java） 主从 Reactor 多线程 epoll/IOCP
libuv（Node.js） Reactor epoll/kqueue/IOCP
Kestrel（.NET） Reactor epoll/IOCP + Pipelines
Tomcat NIO Reactor epoll/IOCP
Boost.Asio 可 Reactor/Proactor io_uring/IOCP
Windows IOCP Proactor IOCP

七、.NET 的 Kestrel 怎么对应

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Kestrel 是 ASP.NET Core 的服务器，Transport 层是 Reactor：

 Transport（传输层）— Reactor 模式
 基于 epoll（Linux）/ IOCP（Windows）
 用 System.IO.Pipelines 处理网络数据
 接收连接、读取字节流

 应用层 — async/await
 看似 Proactor 风格（await 不阻塞）
 但底层 Transport 是 Reactor（事件就绪通知）
 await 在等数据时释放线程，数据就绪后继续

 所以 Kestrel = Reactor（底层）+ 异步编程模型（上层）
 这也是为什么 Kestrel 跨平台性能都强

八、小结

Reactor：同步 I/O 多路复用 + 事件分发，“数据来了你自己读”
- 单 Reactor 单线程（Redis 6.0 前）
- 单 Reactor 多线程
- 主从 Reactor 多线程/多进程（Nginx、Netty）—— 高性能标配
Proactor：异步 I/O，“我帮你读好了”
- Windows IOCP、Linux io_uring
主流是 Reactor，因为 Linux epoll 成熟；io_uring 普及后 Proactor 会更多
Kestrel = Reactor 底层 + async/await 上层

下一篇讲零拷贝技术（sendfile/mmap/splice）——高性能网络 I/O 的另一块拼图。

操作系统学习笔记（二）：进程、线程与协程

Sat, 09 May 2026 10:00:00 +0800

写在前面

本文讲清三个执行单元：进程、线程、协程。它们的本质区别是什么、开销差多少、各自适合什么场景。理解了这些，才能理解为什么 Go 用协程、Nginx 用多进程、Java 用线程池。

一、进程（Process）

1.1 什么是进程

1
2
3
4
5
6
7
8
9


进程 = 程序的一次运行实例，是资源分配的基本单位

每个进程有：
 - 独立的虚拟地址空间（代码、数据、堆、栈）
 - 独立的页表
 - 文件描述符表、信号处理、工作目录等
 - PID（进程ID）

 隔离性极强：A 进程崩了不影响 B 进程

1.2 创建与开销

1
2
3
4
5
6


// Linux 创建进程
pid_t pid = fork(); // 复制当前进程
if (pid == 0) {
 // 子进程
 exec("/bin/program"); // 执行新程序
}

1
2
3
4
5
6
7
8


fork 的开销（很大）：
 - 复制页表（写时复制 COW 优化，但仍有开销）
 - 分配新的内核栈、task_struct
 - 拷贝文件描述符、信号表等
 - 大约 几百微秒 ~ 几毫秒

 进程间通信（IPC）也贵：管道、消息队列、共享内存、Socket
 因为地址空间独立，数据要跨边界拷贝

二、线程（Thread）

2.1 什么是线程

1
2
3
4
5
6
7
8
9


线程 = 进程内的执行单元，是 CPU 调度的基本单位

同一进程的多个线程：
 ✓ 共享地址空间（代码、堆、全局变量）
 ✓ 共享文件描述符
 ✗ 各自有独立的栈、寄存器、PC（程序计数器）

 创建比进程轻量，通信比进程快（共享内存，不用跨边界）
 但共享带来并发问题：需要锁

2.2 用户线程 vs 内核线程

1
2
3
4
5
6
7
8
9


内核线程：
 由操作系统内核管理、调度
 能被内核看到、能多核并行
 .NET/Java 的线程默认是内核线程（1:1 模型）

用户线程（绿色线程/M:N）：
 由用户态运行时管理（Go、Erlang）
 内核看不到，M 个用户线程映射到 N 个内核线程
 创建极轻量，调度在用户态完成

2.3 线程的开销

1
2
3
4
5
6
7
8


创建线程：约 几十微秒（比进程快，但仍不算便宜）
上下文切换：约 1~10 微秒
 - 保存/恢复寄存器
 - 切换内核栈
 - TLB/缓存失效（隐性开销最大）

线程栈：默认 1~8MB（1万个线程 = 10GB+ 内存）
 所以"一个连接一个线程"撑不住 C10K

三、进程 vs 线程

1
2
3
4
5
6
7
8
9


 进程 线程
─────────────────────────────────────────────────
地址空间 独立 共享
创建开销 大（几百μs~ms） 小（几十μs）
通信 贵（IPC） 便宜（共享内存）
切换开销 大 小
并发问题 无（隔离） 有（需锁）
崩溃影响 只影响自己 整个进程崩
多核利用 能 能

1
2
3
4
5
6
7
8
9


为什么 Nginx 选多进程：
 Worker 进程独立，一个崩了不影响其他
 无锁，简单可靠
 配合事件驱动，单进程抗万级并发

为什么 Java/.NET 传统用多线程：
 线程比进程轻量
 共享内存通信方便
 但要小心锁和线程安全

四、协程（Coroutine）

4.1 什么是协程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


协程 = 用户态的轻量级线程，由程序（运行时）自己调度

特点：
 ✓ 完全在用户态，内核不感知
 ✓ 创建开销极小（几百字节，几纳秒）
 ✓ 切换不进内核，只保存寄存器（纳秒级）
 ✓ 一个线程内可以跑成千上万个协程
 ✗ 协作式调度（需主动让出，或运行时在安全点抢占）

 代表：Go goroutine、Kotlin coroutine、Python async/await、Rust async

4.2 协程的优势

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


创建成本：
 线程：栈 1MB + 内核对象 → 创建几十微秒
 协程：初始栈 2~8KB（可动态增长）→ 创建几纳秒

 Go 程序轻松开 10 万 goroutine，毫无压力
 开 10 万线程则内存和调度都崩

切换成本：
 线程切换：进内核、保存寄存器、TLB 失效 → 1~10μs
 协程切换：用户态保存寄存器 → 几十纳秒

 差 100~1000 倍

4.3 协程的两种实现

1
2
3
4
5
6
7
8
9


1. 有栈协程（Stackful）
 每个协程有自己的栈
 可在任意位置挂起（抢占友好）
 代表：Go goroutine、Lua coroutine

2. 无栈协程（Stackless）
 基于状态机（编译器转换）
 只能在特定点挂起（await 点）
 代表：C# async/await、Rust async、C++20 coroutine、Python async/await

五、调度模型

5.1 抢占式 vs 协作式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


抢占式调度（内核线程）：
 内核按时间片强制切换
 一个线程卡死不影响其他
 .NET/Java 线程、操作系统进程

协作式调度（协程）：
 协程主动让出 CPU（await / yield）
 一个协程不让出，其他协程饿死
 Go 在函数调用点抢占（部分抢占）；纯 async/await 需在 await 让出

 这就是为什么"协程里不能阻塞"——阻塞会卡住整个线程上的所有协程

5.2 Go 的 GMP 模型

1
2
3
4
5
6
7
8
9


Go goroutine 的调度（M:N）：
 G = Goroutine（用户协程）
 M = Machine（内核线程）
 P = Processor（逻辑处理器，持有可运行 G 的本地队列）

 N 个 G 在 M 个 M 上跑，M 个 M 绑定到 P（通常 = CPU 核数）
 P 的本地队列 + 全局队列 + 工作窃取（work stealing）

 效果：goroutine 创建极轻，调度高效，自动负载均衡多核

5.3 .NET 线程池

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


.NET 用内核线程 + 线程池：
 池化复用线程，避免频繁创建销毁
 按需增长（IO 密集型增长快）
 async/await 在线程池线程上跑，等待时释放线程

 对比 Go：
 Go 用协程（M:N），轻量
 .NET 用线程 + async（线程少，靠异步等 I/O 时不占线程）

 思路不同，目标都是高并发：
 Go：协程够轻，开很多协程
 .NET：协程少，靠异步不让线程等

六、上下文切换

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


上下文切换 = 保存当前执行状态、恢复另一个的状态

进程切换：最贵
 切换地址空间（页表）→ TLB 失效 → 内存访问变慢

线程切换：中等
 同进程内，地址空间不变，TLB 不全失效
 但仍进内核、保存寄存器

协程切换：最便宜
 纯用户态，只保存少量寄存器
 不进内核，缓存不失效

 所以协程能轻松百万并发，线程万级就吃力

七、如何选择

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


场景 推荐
──────────────────────────────────────────────────────
需要强隔离（如浏览器多标签） 多进程（Chrome 每标签一进程）
CPU 密集并行计算 线程池 / 协程池
高并发 I/O（万级连接） 协程 / 事件驱动（epoll）
语言原生支持协程（Go） goroutine
语言原生 async（C#/JS） async/await
传统多线程代码 线程 + 锁（但要小心）

通用建议：
 I/O 密集 → 协程或异步（不阻塞）
 CPU 密集 → 多线程/多进程（多核并行）

八、小结

进程：资源分配单位，独立地址空间，隔离强但开销大
线程：CPU 调度单位，共享地址空间，轻量但要锁
协程：用户态轻量线程，创建/切换极便宜，适合高并发
调度：抢占式（线程）vs 协作式（协程，不能阻塞）
Go GMP：M:N 调度 + 工作窃取；.NET：线程池 + async/await
选择：I/O 密集用协程/异步，CPU 密集用多线程多核并行

下一篇讲 Reactor / Proactor 模式——I/O 模型如何变成实际的网络框架。

操作系统学习笔记（一）：I/O 模型全解

Fri, 08 May 2026 10:00:00 +0800

写在前面

本文是操作系统底层系列第一篇，系统讲清楚 5 种 I/O 模型：阻塞、非阻塞、多路复用、信号驱动、异步。理解这些是理解 Nginx、Redis、Netty、Kestrel 为什么快的根基。

之前在 Nginx 系列聊过 epoll，这里从操作系统层面把整个 I/O 模型体系讲全。

一、I/O 的本质

1.1 为什么要懂 I/O 模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


程序 99% 的时间在等 I/O（网络、磁盘）
CPU 处理只是零头

I/O 慢的根本：
 CPU：纳秒级
 内存：百纳秒级
 网络/磁盘：毫秒级（比 CPU 慢 100 万倍）

所以高效程序的核心：不让 CPU 陪 I/O 等
不同 I/O 模型 = 不同的"等待方式"

1.2 用户空间与内核空间

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


操作系统分两层：
 用户空间（User Space）— 应用程序运行的地方
 内核空间（Kernel Space）— 操作系统内核，能直接碰硬件

应用不能直接读写硬件（网卡、磁盘），必须通过「系统调用」请求内核代劳。

一次 read() 的流程：
 1. 应用调用 read()（系统调用）
 2. 切换到内核态
 3. 内核等数据到达网卡/磁盘
 4. 内核把数据从内核缓冲区拷贝到用户缓冲区
 5. 切换回用户态，应用拿到数据

两个阶段：
 阶段1：等待数据就绪（数据从硬件到内核缓冲区）—— 慢，主要耗时
 阶段2：数据拷贝（内核缓冲区 → 用户缓冲区）—— 快

1
2
3


所有 I/O 模型的区别，就在于「应用如何处理这两个阶段」：
 阶段1（等数据）：阻塞？轮询？被通知？
 阶段2（拷贝）：谁拷贝？什么时候拷？

二、阻塞 I/O（Blocking I/O）

最传统的模型。应用调用 read() 后，一直阻塞到数据读完。

1
2


// 应用代码
int n = read(fd, buf, size); // 阻塞在这，直到数据读完

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


时间线：
 应用 read() ──阻塞─────────────────────── 拿到数据
 │
 内核 等数据就绪 ──── 拷贝数据 ─→
 （阶段1） （阶段2）

 阶段1、阶段2 都阻塞应用线程

问题：一个线程只能等一个 fd
 1万个连接 = 1万个线程傻等
 这就是 C10K 问题的根源

三、非阻塞 I/O（Non-blocking I/O）

应用调用 read()，如果数据没就绪，立即返回错误（EAGAIN），不阻塞。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 设置 fd 为非阻塞
fcntl(fd, F_SETFL, O_NONBLOCK);

// 循环轮询
while (1) {
 int n = read(fd, buf, size);
 if (n == -1 && errno == EAGAIN) {
 // 数据没就绪，干点别的，待会儿再问
 continue;
 }
 // 有数据了
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


时间线：
 应用 read()→EAGAIN read()→EAGAIN read()→数据 拿到数据
 （立即返回） （立即返回） （拷贝）
 │
 内核 等数据就绪 ──── 拷贝 ─→

 阶段1 不阻塞（轮询），但阶段2（拷贝）仍阻塞

问题：轮询浪费 CPU（空转）
 不停 read 大部分返回 EAGAIN，CPU 全耗在询问上
 很少单独用，通常配合多路复用

四、I/O 多路复用（select / poll / epoll）

一个线程同时监控多个 fd，谁有数据就处理谁。这是高并发的核心。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// epoll 用法（简化）
int epfd = epoll_create1(0);

// 注册关心的 fd
epoll_ctl(epfd, EPOLL_CTL_ADD, fd1, &event);
epoll_ctl(epfd, EPOLL_CTL_ADD, fd2, &event);

// 等待（阻塞，直到有 fd 就绪）
int n = epoll_wait(epfd, events, max, -1);
// n = 就绪的 fd 数量，只返回有数据的
for (i = 0; i < n; i++)
 handle(events[i]); // 处理（read 时阶段2仍阻塞）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


时间线：
 应用 epoll_wait() ──阻塞（等任意fd就绪）──→ 返回就绪 → read（拷贝）
 │
 内核 监听fd1,fd2... fd2数据到 → 通知 → 拷贝

 阶段1：交给内核多路复用，应用只等通知（不轮询）
 阶段2：read 拷贝时仍阻塞（但很快）

 1个线程管理上万 fd，谁就绪处理谁
 Nginx / Redis 的核心

select / poll / epoll 对比

1
2
3
4
5
6
7
8


 select poll epoll
────────────────────────────────────────────────────────────────
连接数限制 1024（FD_SETSIZE） 无限制 无限制
每次调用 传全部 fd 传全部 fd 只 epoll_wait
内核检查 遍历全部 fd O(n) 遍历全部 O(n) 就绪回调 O(1)
返回结果 全部 fd（再遍历） 全部（再遍历） 只返回就绪的
数据结构 位图 数组 红黑树+就绪链表
适用 连接少 连接多 连接多+活跃少（最佳）

（epoll 细节见 Nginx 系列第二篇，这里不重复。）

五、信号驱动 I/O（Signal-driven）

应用告诉内核"fd 有数据时给我发信号"，然后去干别的。数据就绪时内核发 SIGIO 信号。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 开启信号驱动
fcntl(fd, F_SETFL, O_ASYNC);
fcntl(fd, F_SETOWN, getpid()); // 信号发给当前进程

// 注册信号处理函数
signal(SIGIO, handler);

// 应用继续干别的，数据就绪时 handler 被调用
void handler(int sig) {
 read(fd, buf, size); // 此时数据已就绪，拷贝很快
}

1
2
3
4
5
6
7
8
9


时间线：
 应用 注册信号 → 干别的 ... 被信号打断 → read（拷贝）
 ↑SIGIO
 内核 等数据就绪 ─── 发信号 ─→ 拷贝

 阶段1：不阻塞，靠信号通知
 阶段2：read 仍阻塞

 用得少（信号处理复杂、队列溢出问题），UDP 场景偶有使用

六、异步 I/O（AIO，真正的异步）

前 4 种模型，阶段2（数据拷贝）都还是要应用自己 read。异步 I/O 让内核连拷贝都做完，再通知应用。

1
2
3
4
5
6


// POSIX AIO（Linux）/ IOCP（Windows）
struct aiocb cb = { .aio_fildes = fd, .aio_buf = buf, .aio_nbytes = size };
aio_read(&cb); // 立即返回，内核自己去等+拷贝

// 应用继续干别的
// 内核完成（等数据 + 拷贝）后，发信号/回调通知

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


时间线：
 应用 aio_read() → 立即返回，干别的 ... → 通知（数据已在 buf）
 ↑
 内核 等数据就绪 ─── 拷贝到 buf ─→ 通知

 阶段1、阶段2 都由内核完成，应用完全不阻塞
 这是真正的异步（前面 4 种都是"同步 I/O"的不同等待方式）

Linux 的 AIO：
 - POSIX aio：用户态模拟，性能一般
 - io_uring（Linux 5.1+）：新一代高性能异步 I/O，接近 Windows IOCP
 Windows IOCP：成熟的高性能异步 I/O

七、五种模型对比

1
2
3
4
5
6
7


 阶段1(等数据) 阶段2(拷贝) 是否真异步
──────────────────────────────────────────────────────
阻塞 I/O 阻塞 阻塞 否
非阻塞 I/O 轮询(不阻塞) 阻塞 否
I/O 多路复用 阻塞(等通知) 阻塞 否
信号驱动 I/O 信号通知 阻塞 否
异步 I/O 内核完成 内核完成 是 ✓

1
2
3
4
5
6


前 4 种本质都是「同步 I/O」——阶段2（拷贝）都要应用自己干
只有第 5 种是「真正的异步」——内核把活全干了

 Reactor 模式（Nginx/Redis/Netty）= 用 I/O 多路复用 + 同步处理
 Proactor 模式（Windows IOCP） = 用异步 I/O
 （详见本系列 Reactor/Proactor 篇）

八、概念澄清：同步/异步 vs 阻塞/非阻塞

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


这两个维度容易混，区分清楚：

阻塞 vs 非阻塞（调用方的行为）：
 阻塞 — 调用后线程挂起，直到有结果
 非阻塞 — 调用立即返回（没有结果就返回错误）

同步 vs 异步（结果如何获取）：
 同步 — 调用方主动去拿结果（read 自己拷贝数据）
 异步 — 被调用方做完后通知调用方（内核拷贝完通知）

组合：
 同步阻塞 = read()（最传统）
 同步非阻塞 = 非阻塞 read() 轮询
 异步 = aio_read()（被通知）

 「异步」必然涉及「通知」，调用方不等，被通知后结果已就绪

九、小结

I/O 两阶段：等数据就绪（慢）+ 数据拷贝（快）
5 种模型：
- 阻塞：简单，一连接一线程
- 非阻塞：轮询，浪费 CPU
- 多路复用：一线程管多 fd，高并发核心（select/poll/epoll）
- 信号驱动：用得少
- 异步 I/O：内核全包，真正异步（io_uring/IOCP）
关键认知：前 4 种都是同步 I/O（拷贝阶段应用自己干），只有异步 I/O 是真异步
概念：阻塞/非阻塞是调用行为，同步/异步是结果获取方式

下一篇讲进程、线程、协程的本质与调度。