Operating System on 纪伟的个人博客

跨平台理解文件系统链接：硬链接、符号链接、Junction 与 bind mount

Sun, 09 Aug 2026 10:00:00 +0800

写在前面

开发中经常会遇到这样的需求：同一份 SDK、离线包或本地文档，希望同时出现在多个项目目录里；切换 Git worktree 时，又不想复制一份几 GB 的资料。Windows 用户可能会想到快捷方式、目录联接（junction），Linux 用户则更熟悉硬链接、符号链接和 bind mount。

这些机制看起来都像“给同一份内容增加入口”，底层含义却完全不同。选错以后，轻则搜索工具看不到文件，重则清理一个工作区时穿过链接删掉真实数据。

本文从路径解析讲起，横向比较 Linux 与 Windows 的几类链接，最后给出 Git worktree 共享本地资料的安全方案。

一、先分清名字、对象和路径

假设程序打开下面的路径：

1

/srv/project/config/app.json

操作系统不是把整个字符串当成一个不可分割的地址，而是从起点开始，逐级解析 srv、project、config 和 app.json。理解各种链接，关键是看其中某一级保存的究竟是什么：

机制	链接中保存或建立的关系	解析结果
硬链接	新名称直接引用同一个文件对象	两个名称地位基本平等
符号链接	保存另一个路径字符串	访问时继续解析目标路径
Windows junction	目录上的 NTFS 重解析点，保存目标目录信息	I/O 管理器按重解析数据转向目标目录
Linux bind mount	把已有文件或目录子树再次挂到目录层次中的另一个位置	从另一个挂载点进入同一子树
Windows 快捷方式	`.lnk` 文件中保存供 Shell 使用的目标和启动信息	只有理解 Shell Link 的应用才会主动解析

1.1 硬链接指向文件对象

在 Linux 常见文件系统中，目录项把文件名映射到 inode；在 NTFS 中，可以近似理解为多个名称关联同一个文件记录。硬链接增加的是同一文件对象的名称，而不是创建一个“目标路径”。

因此，删除其中一个名称通常不会删除文件数据。只有链接计数归零，并且不再有进程打开该文件时，系统才有条件回收相应存储。硬链接不能跨文件系统或卷，因为另一套文件系统无法直接引用本文件系统内部的对象标识；普通接口也不允许给目录创建硬链接，以免目录树出现难以处理的环。

1.2 符号链接指向另一个名称

符号链接（symbolic link，symlink）自身是特殊文件，内容本质上是一个路径字符串。这个路径可以是绝对路径，也可以是相对路径；相对目标以符号链接所在目录为基准解析，而不是以调用者当前工作目录为基准。

目标可以暂时不存在，所以符号链接可能成为悬空链接（dangling symlink）。它还能跨文件系统并指向目录，这是它比硬链接灵活的原因，也是部署、打包和清理工具必须决定“是否跟随链接”的原因。

1.3 Junction 和 bind mount 都不是“目录硬链接”

Windows junction 与 Linux bind mount 都能让一个目录树从另一个位置出现，但它们不是同一种机制：

junction 是 NTFS 目录上的重解析点，目标必须是同一台计算机上的本地目录，可以跨本地卷，但不能直接指向远程共享；
bind mount 是 Linux VFS 的挂载操作，把已有文件或目录子树附加到当前挂载命名空间中的另一个位置，并不创建符号链接文件。

把二者类比有助于选型，但不能把命令、权限和生命周期直接互换。

二、Linux：硬链接、符号链接与 bind mount

下面的示例在一个临时实验目录中执行。先创建原始文件：

1
2
3


mkdir -p ~/link-lab/real
printf 'version 1\n' > ~/link-lab/real/data.txt
cd ~/link-lab

2.1 硬链接：同一个文件的另一个名字

ln 默认创建硬链接：

1
2
3
4
5


ln real/data.txt data-hard.txt

# 两个名称的 inode 编号和链接计数应相同
ls -li real/data.txt data-hard.txt
stat real/data.txt data-hard.txt

修改任意一个名称，另一个名称读取到的也是同一份内容：

1
2
3
4
5
6
7
8
9


printf 'version 2\n' >> data-hard.txt
cat real/data.txt

# 删除原始名称后，另一个硬链接仍然可用
rm real/data.txt
cat data-hard.txt

# 为后面的符号链接实验恢复原始路径
cp data-hard.txt real/data.txt

注意，这里的“不需要管理员权限”不等于不检查权限。创建硬链接仍要求调用者对新名称所在目录拥有相应权限，还会受到文件系统、挂载选项和 Linux 保护策略的约束。

适合硬链接的场景包括同一文件系统内给不可变文件增加名称，或者某些基于链接计数管理文件生命周期的工具。它不适合表示目录别名，也不能表达“始终跟随某个路径的最新替换文件”：如果程序用新文件替换目标路径，旧硬链接仍指向替换前的文件对象。

2.2 符号链接：把另一个路径写进文件

用 ln -s 创建符号链接：

1
2
3
4
5
6
7


# link-lab/shared -> link-lab/real
ln -s real shared

ls -l shared
readlink shared
readlink -f shared
cat shared/data.txt

readlink shared 显示链接中原样保存的目标，readlink -f shared 则尝试规范化并解析为最终路径。由于这里保存的是相对目标 real，整个 link-lab 目录一起移动后，二者的相对关系仍可能保持有效。

删除符号链接自身应针对链接名称操作：

1

rm shared

此操作不会删除 real。但不能据此推断所有递归工具都安全：find、cp、tar、rsync、备份程序和语言运行库各有是否跟随符号链接的选项与默认值。以 GNU find 为例，-P、-H、-L 就代表不同的跟随策略。对陌生清理命令，应先查看文档并在测试目录验证。

2.3 bind mount：在另一个挂载点暴露目录树

如果希望目标在应用看来就是另一个挂载点，或者需要配合挂载命名空间、容器和只读挂载控制，可以使用 bind mount：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


mkdir -p ~/link-lab/real ~/link-lab/mounted
sudo mount --bind ~/link-lab/real ~/link-lab/mounted

# 验证 mounted 确实是挂载点
findmnt --target ~/link-lab/mounted
mountpoint ~/link-lab/mounted

# 使用完毕后先卸载，再删除空目录
sudo umount ~/link-lab/mounted
rmdir ~/link-lab/mounted

bind mount 通常需要 CAP_SYS_ADMIN，普通桌面环境下往往表现为需要 sudo；容器用户命名空间等环境可能另有授权方式。它的生命周期属于挂载体系：临时执行的命令重启后不会自动恢复，需要通过 /etc/fstab、systemd mount unit 或容器运行参数进行持久化。

mount --bind 默认继承底层挂载的属性。若要提供只读入口，应使用系统支持的只读 bind mount 方式并验证实际挂载选项；经典的 bind 后 remount 是多步操作，并非原子的安全边界。对强隔离需求，不能只依赖一条临时挂载命令。

三、Windows：硬链接、符号链接、Junction 与快捷方式

Windows 的 NTFS 支持硬链接、符号链接和 junction。符号链接与 junction 都通过重解析点（reparse point）实现，但使用不同的重解析标签和规则。FAT32 等文件系统不具备完整的 NTFS 链接能力，因此创建前还要确认链接所在卷的文件系统。

3.1 Junction：本地目录的重解析入口

在命令提示符中，mklink /J 创建目录联接：

1
2
3
4
5


mkdir C:\link-lab\real
echo hello>C:\link-lab\real\data.txt

mklink /J "C:\link-lab\shared" "C:\link-lab\real"
type C:\link-lab\shared\data.txt

PowerShell 可以完成同样的操作：

1
2
3


New-Item -ItemType Junction `
 -Path 'C:\link-lab\shared-ps' `
 -Target 'C:\link-lab\real'

Junction 只面向目录，通常不需要提升为管理员。它可以从 C: 指向本机 D: 上的目录，却不能直接指向 UNC 路径或映射的远程卷。mklink /J 也能记录一个尚不存在的目标路径，此时入口在目标出现前不可正常使用。相较于符号链接，它还缺少可随目录整体搬迁的相对目标语义；共享目录改名或迁移后，应重新创建 junction，而不是假定它会自动修复。

3.2 Windows 符号链接：更接近 Linux symlink

mklink 不加 /D 时创建文件符号链接，加 /D 时创建目录符号链接：

1
2


mklink "C:\link-lab\data-link.txt" "C:\link-lab\real\data.txt"
mklink /D "C:\link-lab\shared-symlink" "C:\link-lab\real"

Windows 符号链接支持文件和目录，也支持相对目标。传统环境中，创建符号链接通常要求提升权限；现代 Windows 开启开发者模式后，调用支持 SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE 的工具可以请求非提升创建。最终能否成功仍取决于 Windows 版本、开发者模式、调用工具和安全策略，脚本应检查退出码，而不要仅凭“这是 Windows 11”作判断。

PowerShell 示例：

1
2
3


New-Item -ItemType SymbolicLink `
 -Path 'C:\link-lab\shared-symlink-ps' `
 -Target 'C:\link-lab\real'

3.3 Windows 硬链接：同卷文件的另一个名称

Windows 的硬链接只能用于文件，且所有名称必须位于同一个卷：

1
2


mklink /H "C:\link-lab\data-hard.txt" "C:\link-lab\real\data.txt"
fsutil hardlink list "C:\link-lab\real\data.txt"

不要把硬链接当成“实时复制”。它没有两个独立副本，修改任何一个名称都会修改同一文件；删除一个名称也不会撤销经由其他名称进行的修改。

3.4 `.lnk` 快捷方式：Shell 数据，不是文件系统链接

Windows 快捷方式是扩展名为 .lnk 的二进制 Shell Link 文件，可以保存目标、工作目录、启动参数、图标和热键。资源管理器双击时会解析它，但普通的 open、cd 或路径拼接不会把 folder.lnk\data.txt 自动改写到目标目录。

PowerShell 可以通过 Shell COM 创建快捷方式：

1
2
3
4


$shell = New-Object -ComObject WScript.Shell
$shortcut = $shell.CreateShortcut('C:\link-lab\real.lnk')
$shortcut.TargetPath = 'C:\link-lab\real'
$shortcut.Save()

快捷方式适合面向人的启动入口，不适合给编译器、Git 或服务进程提供路径别名。

3.5 创建之后不要靠图标猜

资源管理器图标只能提供提示。应通过元数据确认链接类型和目标：

1
2


Get-Item -LiteralPath 'C:\link-lab\shared' |
 Format-List FullName,Attributes,LinkType,Target

也可以查询重解析点：

1
2


fsutil reparsepoint query "C:\link-lab\shared"
dir /AL "C:\link-lab"

删除目录 junction 或目录符号链接时，先确认路径本身确实是预期的重解析点，再删除链接入口：

1

rmdir "C:\link-lab\shared"

文件符号链接使用 del 删除。不要为了“保险”随手给未知路径加递归或强制删除参数；不同工具、运行库和版本对重解析点遍历的处理并不完全一致。删除前先检查 LinkType、目标路径和目标中的重要文件是否已有备份。

3.6 Git Bash 中的 `ln -s` 要单独验证

Git Bash 运行在 Git for Windows 携带的 MSYS2 兼容层上，不能把 Linux 中的 ln -s 行为原样套过来。在未启用 Windows 原生链接模式的环境中，ln -s 可能退化为复制目标；针对 Git for Windows 2.55.0.windows.3 的本地实验中，文件和目录都表现为普通副本，而不是重解析点。

需要请求 Windows 原生符号链接时，可以先设置 MSYS 运行时选项：

1
2


export MSYS=winsymlinks:nativestrict
ln -s real shared

nativestrict 的含义是原生符号链接创建失败时让命令失败，而不是静默换成另一种表示。它仍受开发者模式、进程权限和目标文件系统能力约束。创建后应回到 PowerShell 用 Get-Item 或在命令提示符中用 fsutil reparsepoint query 验证，不能只看 ln 是否返回成功。

Git 配置 core.symlinks 主要控制 Git 检出符号链接时的行为，不会自动把当前 Git Bash 会话中的 ln -s 变成 Windows 原生符号链接。这是两层不同的配置。

四、跨平台对照：它们究竟像不像

特性	Linux 硬链接	Windows 硬链接	Linux symlink	Windows symlink	Windows junction	Linux bind mount	Windows `.lnk`
对象类型	文件系统名称	文件系统名称	特殊文件	NTFS 重解析点	NTFS 目录重解析点	挂载关系	普通 Shell Link 文件
可指向文件	是	是	是	是	否	是	是
可指向目录	普通用户接口不允许	否	是	是	是	是	是
可跨文件系统或卷	否	否	是	是	可跨本地卷	是	是
可直接指向远程位置	不适用	否	取决于目标路径和挂载	可以表达路径，访问仍受系统策略约束	否	可绑定已经挂载的远程树	可以
目标可不存在	否	否	是	是	可以，但入口会悬空	否（源与挂载点都需存在，可先预建空挂载点）	可以失效
相对目标	不适用	不适用	是	是	不作为可移植相对链接使用	不适用	Shell 自行解析
常见特殊权限	目录写权限等	目录与文件权限	目录写权限等	提升权限或开发者模式等条件	通常无需提升	通常需要挂载能力	通常无需提升
是否适合程序路径	是	是	是，但工具可选择不跟随	是，但工具可识别重解析点	是，但工具可识别重解析点	是	通常不适合

这张表描述的是常见本地文件系统与标准工具行为。网络文件系统、容器、安全软件和企业策略都可能增加限制，自动化脚本仍应以实际命令结果为准。

五、如何选择

可以按下面的顺序判断：

只是给人提供启动入口：Windows 使用快捷方式；Linux 桌面环境通常使用 .desktop 文件。它们不是程序路径重定向机制。
同一文件系统内让一个文件拥有多个平等名称：使用硬链接。先确认你真正需要共享同一个文件对象，而不是复制或版本管理。
需要跨文件系统、相对路径或文件与目录通用链接：使用符号链接。把工具的跟随策略纳入测试。
Windows 上只需要给本地目录增加稳定入口，并希望免提升创建：junction 往往最省事；远程共享和相对可移植目标不适用。
Linux 上需要挂载命名空间、容器视图或挂载属性控制：考虑 bind mount；它比 symlink 更接近系统部署机制，也需要更严格的权限和生命周期管理。

如果目的只是节省空间，还应先考虑内容寻址缓存、包管理器缓存、Git LFS、制品仓库或写时复制文件系统。链接解决的是命名和可见性，不自动解决版本、完整性、并发写入与供应链可信度。

六、实战：让多个 Git worktree 使用同一份本地资料

6.1 为什么新 worktree 看不到本地资料

git worktree 为同一仓库创建多个工作树。它们共享对象数据库和大部分引用，但每个工作树有独立的检出文件、HEAD 和索引。只有 Git 跟踪的文件会按目标提交检出；主工作树里未跟踪或被忽略的 SDK、文档和本地配置不会自动复制到新工作树。

如果这些资料体积较大且读多写少，可以在所有工作树之外建立一个中立共享区：

1
2
3
4
5
6
7


D:\workspace\sample\
├── main\ # 主工作树
├── feature-a\ # 关联工作树
├── feature-b\ # 关联工作树
└── _local-shared\ # 不属于任何工作树
 ├── docs\
 └── vendor-sdk\

6.2 Windows 使用 junction

分别在工作树中创建入口：

1
2


mklink /J "D:\workspace\sample\main\local-docs" "D:\workspace\sample\_local-shared\docs"
mklink /J "D:\workspace\sample\feature-a\local-docs" "D:\workspace\sample\_local-shared\docs"

把入口名称加入仓库的 .gitignore，或者只在当前克隆的 .git/info/exclude 中忽略：

1

/local-docs/

.git/info/exclude 不会提交到仓库，适合纯本机约定；.gitignore 适合团队都采用相同入口名称的情况。

6.3 Linux 使用 symlink 或 bind mount

普通开发资料通常先选择 symlink：

1
2


ln -s ../_local-shared/docs ~/workspace/sample/main/local-docs
ln -s ../_local-shared/docs ~/workspace/sample/feature-a/local-docs

示例是否能保持相对关系取决于你的实际目录层次，创建后必须验证：

1
2
3


readlink ~/workspace/sample/main/local-docs
readlink -f ~/workspace/sample/main/local-docs
test -r ~/workspace/sample/main/local-docs/index.md

若应用拒绝符号链接，或者需要通过挂载命名空间控制视图，再考虑 bind mount：

1
2
3
4


mkdir -p ~/workspace/sample/main/local-docs
sudo mount --bind ~/workspace/sample/_local-shared/docs \
 ~/workspace/sample/main/local-docs
findmnt --target ~/workspace/sample/main/local-docs

6.4 哪些内容可以共享

适合共享的通常是只读或低频修改内容：

本地设计资料和大体积参考手册；
经过校验、版本固定的厂商 SDK 安装包；
可丢弃、能够重新生成的下载缓存。

以下目录不应在并行 worktree 间共享：

bin/、obj/、构建输出和测试结果；
IDE 状态目录；
运行时数据库、日志和可能并发写入的工作目录；
不同分支可能要求不同版本的依赖展开目录。

链接不会提供并发控制。两个分支同时写入共享目标时，修改会立即互相影响，可能造成难以复现的构建结果。

6.5 不要假定所有工具都会扫描进去

能够执行 type local-docs\guide.txt 或 cat local-docs/guide.txt，只证明按这个明确路径访问可以到达目标，不证明所有工具都会递归遍历：

git grep 面向 Git 已跟踪内容，不会因为目录入口存在就自动索引外部未跟踪资料；
IDE、全文搜索、备份和杀毒工具可能跳过链接、限制在工作区边界内，或要求单独开启跟随链接；
AI 编程工具还可能受工作区沙箱和可写根目录限制，即使操作系统可以解析路径，也不代表工具被授权读取目标。

因此，应在仓库说明文件中记录真实共享目录、用途和只读约定，并让初始化脚本创建入口。验证时直接读取一个哨兵文件，再单独测试 IDE 搜索、构建和 AI 工具需要的能力。

七、真正危险的地方：遍历、删除与信任边界

7.1 工具决定是否跟随链接

操作系统提供路径解析能力，应用程序仍可以查看链接元数据并选择不跟随。文件树遍历工具往往区分下面几种策略：

永不跟随遇到的链接；
只跟随命令行直接指定的链接；
跟随遍历途中遇到的全部链接。

最后一种策略可能走出预期目录、重复扫描同一棵树，甚至遇到环。备份、归档、同步和删除命令都必须查明策略，不能从 cat link/file 成功推导其递归行为。

7.2 删除入口不等于递归清空入口

安全目标通常是“删除链接本身，不碰目标”。Linux symlink 使用 rm link-name；Windows 目录 junction 或目录 symlink 在确认类型后使用 rmdir link-name。不要把未知路径交给未经验证的递归删除工具，也不要在链接路径后随意添加可能改变解析行为的分隔符。

自动化脚本至少应执行三步：

读取并确认链接类型；
解析目标并确认它处于允许范围；
使用删除链接入口的 API，而不是先枚举子项再逐个删除。

重要数据仍然需要独立备份。链接不是备份，也不是回收站。

7.3 链接不能绕过权限

经过链接访问目标时，系统仍会检查路径和目标对象的权限。反过来，如果高权限程序信任低权限用户能够替换的链接，攻击者可能在“检查路径”和“真正打开文件”之间改变目标，形成链接攻击或 TOCTOU（time-of-check to time-of-use）问题。

高权限服务不应把“先取规范化路径，再按字符串判断前缀”当作完整防线。更稳妥的方式是限制可写目录、使用能够约束跟随行为的句柄式 API，并在同一权限边界内完成打开和验证。

7.4 可移植性需要显式设计

Git 可以在类 Unix 系统中记录符号链接，但检出行为会受到文件系统能力和 core.symlinks 等配置影响。Windows junction 本身不是一种可以按同样语义提交并在 Linux 自动还原的 Git 跨平台对象。

因此，本地开发入口更适合由初始化脚本按平台创建：

1
2


setup-local-links.ps1 # Windows: junction 或 symlink
setup-local-links.sh # Linux: symlink，必要时提示 bind mount

脚本应幂等：入口正确时不重复创建，入口存在但目标错误时明确失败，不擅自覆盖真实目录。

八、建立一个最小验证闭环

无论选择哪种机制，完成后都验证四件事：

类型正确：它究竟是硬链接、symlink、junction、挂载点还是 .lnk；
目标正确：相对路径的基准和最终解析位置符合预期；
工具可用：构建、搜索、备份和 AI 工具是否按需要遍历；
删除安全：在只有测试数据的目录里确认删除入口不会删除目标。

Windows 可以这样检查：

1
2
3


$link = Get-Item -LiteralPath 'C:\link-lab\shared'
$link | Format-List FullName,Attributes,LinkType,Target
Test-Path -LiteralPath 'C:\link-lab\shared\data.txt'

Linux 可以这样检查：

1
2
3
4


ls -ld ./shared
readlink ./shared
readlink -f ./shared
findmnt --target ./mounted

如果脚本依赖某个链接，验证失败时应立即退出并给出修复提示，而不是继续执行后续构建或清理步骤。

九、小结

各种“链接”解决的不是同一个问题：

硬链接让同一个文件对象拥有多个名称；
符号链接保存另一个路径，灵活但存在悬空、遍历策略和安全边界；
Windows junction 是面向本地目录的 NTFS 重解析入口；
Linux bind mount 是挂载体系的一部分，适合命名空间和部署视图；
Windows .lnk 是 Shell 快捷方式，不是通用文件系统路径。

在 Git worktree 场景中，junction 和 symlink 很适合把只读本地资料挂入多个工作树，但共享可写输出、假定工具一定递归、或者用未经验证的递归命令清理链接，都可能把便利变成事故。先确定机制，再验证具体工具的行为，最后把创建、检查和删除过程写进脚本，才是可重复的工程方案。

参考资料

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

Sun, 09 Mar 2025 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


虚拟内存的好处：
 ✓ 进程隔离（每个进程独立地址空间，互不干扰）
 ✓ 内存"变多"（虚拟空间可大于物理内存，用磁盘做扩展）
 ✓ 地址抽象（程序使用虚拟地址，不必关心物理位置；ASLR、PIE 等机制还会改变进程间或运行间地址）
 ✓ 按需分配（用到才分配物理页，懒加载）
 ✓ 共享内存（多个进程的虚拟页映射到同一物理页）

1.2 地址翻译

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


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

 虚拟地址空间（64位，实际常用 48 位 = 256TB；较新的 CPU 可选 5 级分页，扩展到 57 位）
 ┌────────────────┐
 │ 用户空间（高地址）│
 │ 栈 ↓ │
 │ 共享库 │
 │ 堆 ↑ │
 │ 数据段 │
 │ 代码段 │
 └────────────────┘
 ┌────────────────┐
 │ 内核空间 │
 └────────────────┘

 每个进程都觉得自己独占这整个空间
 实际物理内存由 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 = 2^36 ≈ 687亿项，每进程页表就几百GB，不可能
 多级：只存用到的部分，按需创建

2.3 TLB（Translation Lookaside Buffer）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

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

 TLB 容量和层级因 CPU 而异，局部性良好时可获得较高命中率

 这就是为什么上下文切换贵：
 切换地址空间可能使部分 TLB 项失效；PCID/ASID 等硬件机制可以保留带地址空间标识的条目

三、缺页中断

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


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

 Minor Page Fault 可通过分配物理页或建立已有映射解决，不需要磁盘 I/O
 Major Page Fault 需要从存储读取页面，延迟显著更高
 内存压力下频繁换入换出会形成抖动（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 为例，阈值可动态调整或配置）：
 较小分配通常从 arena/堆中满足，必要时用 brk 扩展
 brk 指针上移，堆增长
 free 后内存不归还 OS，留作复用
 较大分配可能用 mmap 单独映射；不能把 128KB 当作固定规则
 独立区域，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 与缓存；PCID/ASID 等机制可减少这类代价
 协程切换通常避免内核调度开销，但性能仍取决于运行时实现和任务行为

八、小结

虚拟内存：每进程独立地址空间，隔离+按需分配+可大于物理内存
分页+页表：4KB 页，多级页表映射虚拟→物理
TLB：页表缓存，地址空间切换可能影响其中的条目；现代硬件可用地址空间标识降低代价
缺页中断：页表映射尚未就绪时触发；只有 Major Page Fault 必须从存储读取数据
malloc：用户态分配器通过 arena、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 高性能的底层根基。理解了它们，再看任何中间件、框架的性能文章，都能看懂"为什么"。

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

Fri, 07 Mar 2025 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.2 引入，专门为"文件→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)→ 网卡

 数据不进用户态！
 3 次拷贝（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 的输入必须是支持类似 mmap 读取的文件，输出在 Linux 2.6.33 前只能是 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 在合适的消息大小、批量、副本和硬件条件下获得较高吞吐

6.3 Java 的零拷贝 API

1
2
3
4
5


Java NIO：
 FileChannel.transferTo() → 可由平台实现映射到 sendfile 等高效传输路径
 MappedByteBuffer → 使用内存映射文件能力

 Kafka、Netty 等系统会利用这些 API 减少用户态复制；实际路径取决于平台和运行时

七、.NET 的零拷贝

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


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

ASP.NET Core 的静态文件中间件：
 主要把文件流复制到响应流，配合 Pipelines 减少分配
 Linux 下默认未走内核 sendfile 路径（社区长期有相关优化请求）

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 模式

Wed, 05 Mar 2025 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 等多 Reactor 框架。Nginx 的 master 主要负责配置与 Worker 生命周期，连接通常由 Worker 接受和处理

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

二、Nginx 的 Reactor 架构

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


Nginx = 多进程 Reactor 版（与 Netty 的主从 Reactor 不同）：

 Master 进程
 │ 读取配置、管理 Worker 生命周期（不处理连接）
 │
 Worker 进程 ×N（通常 = CPU 核数）
 各 Worker 从共享监听 socket 上 accept 新连接
 每个 Worker 自己的 epoll + Reactor
 独立处理连接的读写、业务

 特点：
 多进程 Worker → 较强的故障隔离；共享状态和连接接受协调仍可能使用原子操作或锁
 每个 Worker 一个 Reactor（单线程事件循环）
 共享统计、限流等状态可放在共享内存中，并按模块需要使用同步机制

三、Redis 的事件模型

1
2
3
4
5
6
7
8


Redis 6.0 之前：单 Reactor 单线程
 一个线程跑事件循环 + 命令执行
 为什么快：内存数据结构、事件循环和较少的线程间协调；仍会发生系统调用与调度

Redis 6.0+：单 Reactor + IO 多线程
 经典执行路径主要由主线程串行处理命令；Redis 新版本的部分 I/O、后台任务和模块可使用其他线程
 网络 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 接口适用范围有限
 io_uring（2019）才让 Linux 有了高性能异步 I/O
 epoll + Reactor 已足够高效，生态成熟
 Windows 用 Proactor（IOCP）

 io_uring 扩展了完成通知式设计的选择，但框架仍可能采用 Reactor、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 多线程（Netty）、多进程 Reactor（Nginx）—— 高性能标配
Proactor：异步 I/O，“我帮你读好了”
- Windows IOCP、Linux io_uring
主流是 Reactor，因为 Linux epoll 成熟；io_uring 普及后 Proactor 会更多
Kestrel = Reactor 底层 + async/await 上层

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

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

Mon, 03 Mar 2025 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) {
 // 子进程
 execl("/bin/program", "program", NULL); // 执行新程序
}

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


创建线程和上下文切换都不是固定常数，会受操作系统、CPU、调度、NUMA 和负载影响
 - 保存/恢复寄存器
 - 切换内核栈
 - TLB/缓存失效（隐性开销最大）

线程栈上限或保留空间常见为 MB 量级，但实际提交的物理内存、默认值和增长方式因平台与运行时而异
 所以"一个连接一个线程"撑不住 C10K

三、进程 vs 线程

1
2
3
4
5
6
7
8
9


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

1
2
3
4
5
6
7
8
9


为什么 Nginx 选多进程：
 Worker 进程独立，一个崩了不影响其他
 Worker 之间大部分请求状态相互隔离，但共享内存区、accept 协调等路径仍可能使用原子操作或锁
 配合事件驱动，单进程抗万级并发

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

四、协程（Coroutine）

4.1 什么是协程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


协程是由语言或运行时调度的轻量级并发任务；具体实现并不都等同于“用户态线程”

特点：
 ✓ 通常可在较少的内核线程上承载大量并发任务
 ✓ 通常比操作系统线程占用更少资源
 ✓ 任务间切换通常不需要每次进入内核调度
 ✗ 栈与状态保存方式依实现而异：goroutine 使用可增长栈，async 任务通常编译为状态机
 ✗ 调度方式也依实现而异，既有 await/yield 协作让出，也有运行时抢占

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

4.2 协程的优势

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


创建成本：
 线程：需要内核调度实体和较大的栈地址空间
 协程：通常由语言运行时管理，可使用较小且可增长的栈

 Go 程序可以承载大量 goroutine，但上限仍受栈增长、调度、文件描述符和业务资源约束
 同数量的内核线程通常成本更高，但不能脱离工作负载给出固定容量结论

切换成本：
 线程切换通常需要内核调度；同进程线程不会更换地址空间
 协程切换通常由运行时在用户态调度，但遇到系统调用、抢占和工作窃取时成本会变化

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 调度器既使用安全点，也从 Go 1.14 起支持异步抢占；纯 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：不依赖海量线程，等待 I/O 时释放线程

六、上下文切换

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


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

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

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

协程切换：最便宜
 通常由语言运行时完成，不必每次进入内核调度
 具体保存状态和缓存影响取决于协程实现

 因而协程常适合大规模 I/O 并发，但可承载数量仍受栈、任务状态、连接和业务内存约束

七、如何选择

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


场景 推荐
──────────────────────────────────────────────────────
需要强隔离（如浏览器站点隔离） 多进程
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 模型全解

Sat, 01 Mar 2025 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


许多 I/O 密集型程序的大量时间用于等待网络或磁盘
此时瓶颈往往不在业务计算本身

I/O 慢的根本：
 CPU 指令与缓存命中：常见为纳秒量级
 DRAM、网络和存储：从几十纳秒到毫秒以上，跨度取决于介质、距离、队列和负载

所以高效程序的核心：不让 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
────────────────────────────────────────────────────────────────
固定集合上限 受 FD_SETSIZE 限制 无固定集合上限 无固定集合上限
每次调用 传全部 fd 传全部 fd 只 epoll_wait
等待成本 遍历全部 fd O(n) 遍历全部 O(n) 通常随就绪事件数增长
返回结果 全部 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（提交与完成分离）

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

1
2
3
4
5
6


// POSIX AIO 接口示意；glibc 在普通文件上通常借助线程实现，不能等同于内核原生异步 I/O
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
13


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

 提交调用通常快速返回，完成后再通知应用；具体路径是否真正异步取决于接口、文件类型、内核与驱动
 这是完成通知式模型；底层工作由内核、驱动或实现线程协作完成

Linux 的 AIO：
 - glibc POSIX AIO：对普通文件通常由用户态线程池模拟
 - Linux native AIO：接口和适用文件类型有限
 - io_uring（Linux 5.1+）：统一的提交/完成队列接口；是否走异步路径及安全边界取决于操作和内核版本
 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()（被通知）

 异步完成通常通过回调、事件、Future 或完成队列等机制交付结果

九、小结

I/O 两阶段：等数据就绪（慢）+ 数据拷贝（快）
5 种模型：
- 阻塞：简单，一连接一线程
- 非阻塞：轮询，浪费 CPU
- 多路复用：一线程管多 fd，高并发核心（select/poll/epoll）
- 信号驱动：用得少
- 异步 I/O：提交与完成分离（如 io_uring/IOCP），具体执行路径依实现而定
关键认知：不要仅凭 API 名称判断是否阻塞；应区分提交、等待、数据传输和完成通知
概念：阻塞/非阻塞是调用行为，同步/异步是结果获取方式

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

Operating System on 纪伟的个人博客

跨平台理解文件系统链接：硬链接、符号链接、Junction 与 bind mount

写在前面

一、先分清名字、对象和路径

1.1 硬链接指向文件对象

1.2 符号链接指向另一个名称

1.3 Junction 和 bind mount 都不是“目录硬链接”

二、Linux：硬链接、符号链接与 bind mount

2.1 硬链接：同一个文件的另一个名字

2.2 符号链接：把另一个路径写进文件

2.3 bind mount：在另一个挂载点暴露目录树

三、Windows：硬链接、符号链接、Junction 与快捷方式

3.1 Junction：本地目录的重解析入口

3.2 Windows 符号链接：更接近 Linux symlink

3.3 Windows 硬链接：同卷文件的另一个名称

3.4 .lnk 快捷方式：Shell 数据，不是文件系统链接

3.5 创建之后不要靠图标猜

3.6 Git Bash 中的 ln -s 要单独验证

四、跨平台对照：它们究竟像不像

五、如何选择

六、实战：让多个 Git worktree 使用同一份本地资料

6.1 为什么新 worktree 看不到本地资料

6.2 Windows 使用 junction

6.3 Linux 使用 symlink 或 bind mount

6.4 哪些内容可以共享

6.5 不要假定所有工具都会扫描进去

七、真正危险的地方：遍历、删除与信任边界

7.1 工具决定是否跟随链接

7.2 删除入口不等于递归清空入口

7.3 链接不能绕过权限

7.4 可移植性需要显式设计

八、建立一个最小验证闭环

九、小结

参考资料

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

写在前面

一、虚拟内存

1.1 为什么需要虚拟内存

1.2 地址翻译

二、分页与页表

2.1 分页机制

2.2 页表

2.3 TLB（Translation Lookaside Buffer）

三、缺页中断

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

4.1 用户态分配

4.2 内存碎片

4.3 高性能内存分配器

五、内存池

六、页面置换

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

八、小结

系列总结

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

写在前面

一、传统读写的开销

1.1 传统方式

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

三、sendfile（真正的零拷贝）

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

四、splice（管道零拷贝）

五、对比总结

六、实际应用

6.1 Nginx

6.2 Kafka

6.3 Java 的零拷贝 API

七、.NET 的零拷贝

八、小结

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

写在前面

一、Reactor 模式

1.1 核心思想

1.2 三种 Reactor 实现

单 Reactor 单线程

单 Reactor 多线程

主从 Reactor 多线程（最常用）

二、Nginx 的 Reactor 架构

三、Redis 的事件模型

四、Proactor 模式

五、Reactor vs Proactor

3.4 `.lnk` 快捷方式：Shell 数据，不是文件系统链接

3.6 Git Bash 中的 `ln -s` 要单独验证