Linux IO 模型纵深解析 01：从 Unix 传统到 Linux 内核的 IO 第一性原理

从 Unix 传统到 Linux 内核的 IO 第一性原理 ------ 为什么"一切皆文件"不是口号，而是内核级设计约束

Key Words：Unix IO、VFS、file、inode、page cache、system call、阻塞语义、同步 IO、设备抽象、POSIX

如果只从接口层看 Linux IO，世界会显得异常"简单"：read/write、select/poll/epoll、阻塞与非阻塞，API 形态规整得近乎教科书。但凡你真正顺着一次 IO 的路径往下钻------从 libc 的薄封装一路踩进内核，从 VFS 到具体文件系统，从 page cache 到设备驱动，再落到 DMA 与中断------很快就会意识到：Linux IO 模型不是一组 API 的集合，而是一套在历史、硬件与工程权衡中反复博弈出来的抽象体系。

这篇文章刻意不从"模型分类"讲起，也不会一上来就画 select vs epoll 的对比表。这里要做的是一件更底层、也更"危险"的事情：把 Linux IO 拆回到它的第一性原理，解释清楚几个看似朴素、但决定了一切后续设计走向的问题。

为什么 Unix 会选择"文件"作为 IO 的统一抽象？

为什么阻塞语义会成为默认，而非例外？

为什么 page cache 能横跨文件 IO 与匿名内存？

为什么 Linux 直到 5.x 之后才真正开始动摇传统同步 IO 的地基（io_uring）？

这些问题不回答清楚，后面再讨论多路复用、异步 IO、本质上都只是"技巧层"的优化，而不是对模型的理解。

本文是《Linux IO 模型纵深解析》系列的总起点 。在结构上，会有一条明确的纵向穿梭线索贯穿全文：
应用层 IO API → 抽象统一的内核对象 → 系统调用入口 → 内核 IO 处理主路径 → 硬件与驱动反馈 。

这条线索在后续每一篇（阻塞 / 非阻塞 / 多路复用 / io_uring）中都会被反复复用、对比和打破。

文中会提前埋下几个重要锚点：

一是 VFS 这一层"被严重低估"的设计重量，它决定了 IO 模型讨论的边界；

二是 struct file、struct inode 这些结构体背后真实承担的权责，而不是字段罗列；

三是阻塞语义在调度器、等待队列和硬件中断之间的真实落点；

四是历史包袱如何一步步把 Linux 推到今天这个看似复杂、实则自洽的位置。

$!NOTE$
这篇文章不会教你"怎么用 epoll"，而是要让你在看到任何 IO 接口时，能本能地问出一句："它到底在内核里等的是什么？"

从写作风格上，这是偏"白板推演"的笔记，而不是教程。很多地方会从 C 代码突然跳到硬件，从 POSIX 规范跳到 70 年代 Unix 的工程现实，再拉回到今天的内核实现，因为 IO 本身就是一个横跨软件栈的系统性问题。

如果你是为了准备面试，这篇文章会频繁戳中那些看似基础、却最容易被问穿的问题；

如果你是为了做高性能系统或读内核源码，这里会给你一张"认知地图"，避免在细节中迷路。

下面正式进入第一章之前，需要先把一个最核心的认知钉牢：

Linux IO 模型讨论的从来不是"快不快"，而是在不确定性世界里，内核如何为进程提供可组合、可推理的等待语义。

接下来，我会从 Unix IO 抽象的历史起点 开始，一步步把这套模型拆开。

文章目录

- [从 Unix 传统到 Linux 内核的 IO 第一性原理 ------ 为什么"一切皆文件"不是口号，而是内核级设计约束](#从 Unix 传统到 Linux 内核的 IO 第一性原理 —— 为什么“一切皆文件”不是口号，而是内核级设计约束)
- [1. 从物理设备到统一 IO 抽象](#1. 从物理设备到统一 IO 抽象)
- - [1.1 从"设备各异"到"接口统一"的根本矛盾](#1.1 从“设备各异”到“接口统一”的根本矛盾)
  - [1.2 文件描述符：进程视角下 IO 世界的唯一锚点](#1.2 文件描述符：进程视角下 IO 世界的唯一锚点)
  - [1.3 VFS：统一抽象的真正落点](#1.3 VFS：统一抽象的真正落点)
  - [1.4 抽象的收益与代价：复杂性的真正来源](#1.4 抽象的收益与代价：复杂性的真正来源)
  - [1.5 一个必须记住的等式](#1.5 一个必须记住的等式)
- [2. file descriptor 的真实含义](#2. file descriptor 的真实含义)
- - [2.1 fd 并不是文件，而是用户态进程私有的极简的"索引句柄"](#2.1 fd 并不是文件，而是用户态进程私有的极简的“索引句柄”)
  - [2.2 fd → struct file → inode：Linux IO 的"三级跳"](#2.2 fd → struct file → inode：Linux IO 的“三级跳”)
  - [2.3 files_struct 与 fdtable：并发与共享的起点](#2.3 files_struct 与 fdtable：并发与共享的起点)
  - [2.4 并发问题的根源：共享的是 file，不是 inode](#2.4 并发问题的根源：共享的是 file，不是 inode)
  - [2.5 dup 系列调用：显式制造共享关系](#2.5 dup 系列调用：显式制造共享关系)
  - [2.6 从 fd 回看 IO 多路复用的钥匙](#2.6 从 fd 回看 IO 多路复用的钥匙)
  - [2.7 一个反问](#2.7 一个反问)
- [3. 一次 read 系统调用的完整旅程](#3. 一次 read 系统调用的完整旅程)
- - [3.1 从一个误解开始：read 关心的不是"有没有数据"](#3.1 从一个误解开始：read 关心的不是“有没有数据”)
  - [3.2 从用户态到内核：sys_read 的入口意义](#3.2 从用户态到内核：sys_read 的入口意义)
  - [3.3 vfs_read：IO 模型的第一道岔路口](#3.3 vfs_read：IO 模型的第一道岔路口)
  - [3.4 O_NONBLOCK：不是"更快"，而是"不睡"](#3.4 O_NONBLOCK：不是“更快”，而是“不睡”)
  - [3.5 等待发生在哪里：file->f_op->read](#3.5 等待发生在哪里：file->f_op->read)
  - [3.6 errno 的哲学：用返回值描述"世界的状态"](#3.6 errno 的哲学：用返回值描述“世界的状态”)
  - [3.7 所有 IO 模型分支，都从这里分叉](#3.7 所有 IO 模型分支，都从这里分叉)
  - [3.8 一个自然但危险的问题](#3.8 一个自然但危险的问题)
- [4. 阻塞 / 非阻塞 / 同步 / 异步的正确坐标系](#4. 阻塞 / 非阻塞 / 同步 / 异步的正确坐标系)
- - [4.1 这一章存在的意义：给 IO 模型"重新定坐标"](#4.1 这一章存在的意义：给 IO 模型“重新定坐标”)
  - [4.2 混乱的根源：两个正交维度被混用](#4.2 混乱的根源：两个正交维度被混用)
  - [4.3 严格二维坐标系：把概念放回该在的位置](#4.3 严格二维坐标系：把概念放回该在的位置)
  - [4.4 同步 API ≠ 阻塞语义：read 是最好的反例](#4.4 同步 API ≠ 阻塞语义：read 是最好的反例)
  - [4.5 等待发生在何处，才是判据](#4.5 等待发生在何处，才是判据)
  - [4.6 为什么 Linux 的"文件异步化"如此困难](#4.6 为什么 Linux 的“文件异步化”如此困难)
  - [4.7 等待机制的语义锚点：wait queue](#4.7 等待机制的语义锚点：wait queue)
  - [4.8 面试高频纠偏清单](#4.8 面试高频纠偏清单)
  - [4.9 语义漂移考古：asynchronous 到底在说谁](#4.9 语义漂移考古：asynchronous 到底在说谁)
  - [4.10 为什么"等待"是操作系统的永恒主题](#4.10 为什么“等待”是操作系统的永恒主题)
  - [4.11 承上启下：下一步必须直面"等待本身"](#4.11 承上启下：下一步必须直面“等待本身”)

1. 从物理设备到统一 IO 抽象

内核层次定位：VFS 抽象层（用户态 syscall → 内核态对象模型）

1.1 从"设备各异"到"接口统一"的根本矛盾

早期计算机谈 IO，本质上谈的是设备。磁带机一次只能顺序读，打孔卡是批量输入，行式打印机完全没有"回读"概念。每一种外设都有一套完全不同的时序、缓冲方式和错误模型，程序员必须显式理解"我在跟哪种机器打交道"。IO 代码与设备型号强绑定，换一块硬件，用户态逻辑就得推倒重来。

Unix 出现之前，这种"设备语义外溢到应用层"的模式是常态。Multics 试图通过极其复杂的系统来屏蔽这些差异，但代价是实现与理解成本都高得离谱。Ken Thompson 在 PDP-7 上写 Unix 时，做了一个当时看来非常激进、甚至有点"偷懒"的选择：不去刻画设备差异，而是强行把它们压进同一个抽象里。

这个抽象后来被总结成一句广为流传的话："Everything is a file"。但如果把它理解成"语法糖"或者"API 风格统一"，那几乎是完全误解。这里的 file 不是磁盘文件，而是一种可被进程持有、可被内核调度、可被等待的 IO 对象模型 。

关于一切皆文件的设计哲学本人之前也有过一篇笔记：

# 万字长文外加示例：进入内核理解Linux 文件描述符(fd) 和 "一切皆文件" 理念

$!NOTE$
"一切皆文件"解决的不是"怎么读写"，而是进程如何在不知道设备细节的前提下，与 IO 世界建立稳定关系。

1.2 文件描述符：进程视角下 IO 世界的唯一锚点

从用户态看，Linux IO 的入口永远是一个整数：int fd。这个设计极其克制，也极其冷酷。内核明确拒绝让应用直接持有"设备对象""内核指针"或"通道句柄"，而是通过 fd 建立一层间接性极强的引用关系。

fd 的本质，是 task_struct -> files_struct -> fdtable 中的一个索引。它不是资源本身，只是进程私有的视角映射。同一个内核对象（比如 socket、pipe、文件）可以被多个 fd 引用，也可以在不同进程中拥有不同的 fd 值。这种设计让 IO 资源的生命周期、共享关系和权限控制，全部收敛到内核。

反直觉但正确的一点在这里：fd 的"廉价"是故意的。一个 fd 只是一个整数，dup/close 的成本极低，进程可以随意复制、重定向、继承它。这为 shell 的管道、重定向、守护进程的 fd 继承奠定了基础，也决定了 IO 抽象天然是"进程中心化"的，而不是"设备中心化"的。

1.3 VFS：统一抽象的真正落点

如果说 fd 是用户态的锚点，那么 VFS（Virtual File System）就是内核态的抽象熔炉 。VFS 并不关心你读的是 ext4 文件、字符设备、socket，还是一个匿名管道。它关心的是：

这个对象是否支持 read？是否支持 write？是否支持 poll？阻塞时该如何睡眠和唤醒？

从源码路径上看，最典型的入口在 fs/read_write.c。用户态的 read() 系统调用，最终会落到这里，然后经由 struct file 抽象，调用具体实现。

c 复制代码

// syscall -> vfs_read -> file->f_op->read

这里的关键不是函数跳转，而是 struct file / struct inode / struct file_operations 三者的分工。

struct inode 描述的是"这个对象是什么"------它代表文件系统层面的实体，承载权限、大小、时间戳等元数据。它偏静态，生命周期长，多个 file 可以指向同一个 inode。

struct file 描述的是"进程如何使用它"------当前读写位置 f_pos、打开方式(只读，可读可写）、私有数据。它是典型的"会话态"对象，和 fd 强关联。

而真正把"一切皆文件"落地的，是 struct file_operations。read/write 并不是系统调用，而是一组可被替换的行为。字符设备、块设备、socket，各自提供自己的实现，只要遵守这套接口，VFS 就可以无差别调度。实现上被称为面向对象的多态，VFS的一个职能就是提供了抽象

$!IMPORTANT$
IO 抽象的核心不是"统一函数名"，而是统一等待与调度语义：内核知道什么时候该睡、什么时候该醒。

1.4 抽象的收益与代价：复杂性的真正来源

统一抽象带来的第一个直接收益，是编程模型的稳定性。应用不需要关心底层设备是否支持 DMA、是否有中断，只需要面对 fd 和 read/write。Unix 能在几十年内跨越无数硬件平台，靠的正是这层抽象。

但代价同样真实。不同 IO 对象的性能特性天差地别：磁盘有毫秒级延迟，socket 可能被对端阻塞，pipe 依赖调度器。VFS 强行把它们放在同一语义框架下，意味着等待模型必须足够通用，这可能就牺牲了足够高效。

这也是 Linux IO 模型复杂性的根源。复杂性不来自 API 的数量，而来自这样一个事实：
抽象层希望"一视同仁"，而性能目标要求"区别对待"。

为了在不破坏抽象的前提下提高吞吐，内核不断往模型里塞补丁：非阻塞标志、poll 回调、多路复用、异步提交。这些机制不是偶然出现的，而是统一抽象在高并发场景下的必然张力。

$!Question$
如果 read/write 已经统一了一切，为什么高并发服务器几乎从不"直接 read"？

------答案不在 API，而在等待语义是否可控。

1.5 一个必须记住的等式

在 Linux 语境下，IO 模型永远可以拆成两部分：

IO 模型 = 抽象模型 + 等待语义

抽象模型决定了"你能不能用同一套代码操作一切"；

等待语义决定了"你在等什么、等多久、谁来唤醒你"。

后续所有内容------阻塞、非阻塞、多路复用、io_uring------都不是在推翻"一切皆文件"，而是在试图绕开或重塑等待语义的成本。

本章到这里停下，留一个看似简单、但会贯穿整个系列的问题：

$!NOTE$
如果一切都是文件，fd 已经统一了一切，
那为什么 IO 依然是 Linux 中最难、最绕、最容易踩坑的领域之一？

2. file descriptor 的真实含义

内核层次定位：进程管理 + VFS 交汇点

2.1 fd 并不是文件，而是用户态进程私有的极简的"索引句柄"

在用户态，fd 看起来像"文件的代名词"：read(fd, ...)、write(fd, ...)，久而久之，很多人会下意识把 fd 当成"文件本身"。这是理解 Linux IO 模型时最危险、也最常见的认知偏差。

fd 的本质不是资源，而是索引。它只在进程语境 中有意义，是当前进程 task_struct 持有的一张表里的一个编号。这张表叫 files_struct，fd 只是指向其中一个槽位的整数键。

具体内核细节也可以查看：
# 万字长文外加示例：进入内核理解Linux 文件描述符(fd) 和 "一切皆文件" 理念

换句话说，fd 从一开始就被设计成"廉价、可复制、可重排"的东西。它不携带任何 IO 语义，也不承诺资源的独占性。fd 唯一保证的事情是：通过它，内核能在当前进程的文件表中，找到一个 struct file 指针。

$!NOTE$
fd 的意义不在"指向了什么"，而在"谁在用、如何用、何时不用"。

2.2 fd → struct file → inode：Linux IO 的"三级跳"

要真正理解 fd，必须把它放进一条明确的跳转链路里看：

fd → struct file → struct inode

这不是实现细节，而是 Linux IO 模型的骨架。

fd 位于用户态与内核态的边界，它通过系统调用被解析为 current->files->fdt[fd]。这个槽位里放的不是 inode，而是一个 struct file *。
struct file 是"打开实例"，代表一次打开行为，而不是文件实体本身。它记录了当前读写位置 f_pos、打开标志、以及最关键的：f_op。

再往下，struct file 中的 f_inode（或通过 dentry 间接关联）才指向 struct inode。inode 才是真正意义上的"文件对象"，描述磁盘上的实体或设备节点。

这个分层设计直接带来一个反直觉但极其重要的事实：
多个 fd 可以指向同一个 struct file，也可以指向不同的 struct file，但最终落到同一个 inode。

这正是 fork、dup、重定向等机制得以成立的根基。

2.3 files_struct 与 fdtable：并发与共享的起点

fd 的所有权不属于"进程"这个抽象名词，而是属于 struct files_struct。每个 task_struct 中都有一个 files 指针，指向当前进程的文件表。

c 复制代码

struct files_struct {
    struct fdtable *fdt;
};

fdtable 里保存着 fd 到 struct file * 的映射关系，以及位图、引用计数等信息。关键在于：files_struct 本身是可共享的。

在 kernel/fork.c 中，fork 并不会无脑复制整个文件表。默认行为是：

父子进程共享同一个 files_struct，仅增加引用计数。

这意味着 fork 之后，父子进程看到的 fd 编号一致，fd 指向的 struct file 也是同一个。这不是"拷贝"，而是"共享"。

$!IMPORTANT$
fork 后 fd 共享不是历史包袱，而是为了让 shell 管道、重定向和进程继承成立。

2.4 并发问题的根源：共享的是 file，不是 inode

IO 模型中大量微妙的并发行为，都源自一个事实：并发不是发生在 fd 层，而是发生在 struct file 层。

当两个 fd 指向同一个 struct file，它们共享 f_pos。因此 fork 后父子进程同时 write，同一个文件偏移会被推进，写入顺序取决于调度与锁。

当两个 fd 指向不同的 struct file，但 inode 相同（比如各自 open 同一文件），它们拥有独立的 f_pos，但仍会在 inode 层竞争页缓存、磁盘 IO、锁。

IO 模型的复杂性，本质上不是"多线程"，而是多引用路径如何落到同一个内核对象。

$!Question$
面试高频题：fork 之后，父子进程同时对同一个 fd write，会发生什么？

------关键不在"父子"，而在它们是否共享同一个 struct file。

2.5 dup 系列调用：显式制造共享关系

dup、dup2、fcntl(F_DUPFD) 做的事情非常"暴力"：
创建一个新的 fd 槽位，指向同一个 struct file，并增加引用计数。

它们不会复制 file，不会复制 inode，更不会复制底层资源。它们唯一的作用是：在同一个进程里，制造多个 fd 入口，指向同一个打开实例。

这也是为什么 shell 重定向能工作：
dup2(new_fd, 1) 本质上只是让 fd 1（stdout）指向另一个 struct file。

$!TIP$
理解 dup 的关键不是"复制"，而是"共享"。

2.6 从 fd 回看 IO 多路复用的钥匙

到这里，有一个结论必须钉死：
IO 多路复用关注的从来不是 fd，而是 fd 背后的 struct file 是否"可推进"。

select、poll、epoll 监控的不是"整数变化"，而是 file 对应的等待队列、状态位和回调。这也是为什么理解 fd / file / inode 的区分，是后面所有 IO 模型讨论的钥匙。

fd 只是入口，file 才是行为载体，inode 才是资源实体。

2.7 一个反问

$!NOTE$
fd 只是索引，却承载了如此多的并发与语义，

那内核究竟是如何在 file 层面表达"我现在该等 IO 了"？

这个问题，直接把我们带向下一章：阻塞语义与等待队列 。

IO 模型的难点，从这里才真正开始。

3. 一次 read 系统调用的完整旅程

内核层次定位：系统调用路径 + VFS

3.1 从一个误解开始：read 关心的不是"有没有数据"

很多人第一次读 IO 模型时，会下意识把 read 理解成一个"取数据"的动作：要么读到了，要么没读到。但在内核语境里，这个理解是偏的。read 真正关心的不是数据本身，而是------当前这个调用要不要等。

这是 IO 模型里最重要、也最容易被忽略的分水岭。read 是一个同步接口，这一点从 POSIX 到 Linux 从未动摇；但它是否阻塞，是否把当前进程挂起，完全取决于 fd 的状态以及底层对象当下能否"推进"。

$!NOTE$
同步 ≠ 阻塞。

同步描述的是"调用与结果的关系"，阻塞描述的是"调用期间进程是否被调度走"。

3.2 从用户态到内核：sys_read 的入口意义

从代码路径看，read 的入口并不神秘。体系结构相关的系统调用入口位于 arch/*/entry/syscalls/，在完成寄存器保存、权限检查后，统一跳转到内核实现。

逻辑主线非常清晰：

c 复制代码

// 用户态
read(fd, buf, count);

// 内核态
sys_read -> vfs_read -> file->f_op->read

sys_read 的工作极其克制：校验 fd 是否有效，取出 struct file *，然后把控制权交给 VFS。这里有一个设计上的隐含前提：系统调用层不做 IO 语义判断。它既不关心阻塞，也不关心数据来自磁盘还是网络。

真正的分水岭，在 vfs_read 里。

3.3 vfs_read：IO 模型的第一道岔路口

vfs_read 位于 fs/read_write.c，它是 Linux IO 模型的关键节点。这里第一次面对这样一个问题：
如果现在读不到数据，我该怎么办？

函数签名本身已经暴露了设计意图：

c 复制代码

ssize_t vfs_read(struct file *file,
                 char __user *buf,
                 size_t count,
                 loff_t *pos);

它接收的是 struct file，而不是 fd。这意味着，所有判断都发生在 file 层：

当前 file 是否支持 read
是否被 O_NONBLOCK 打开
是否允许睡眠等待

vfs_read 并不直接读数据，而是把调用转发给 file->f_op->read。但在转发之前，它已经决定了一件事：这个 read 调用是否允许进入"等待路径"。

3.4 O_NONBLOCK：不是"更快"，而是"不睡"

O_NONBLOCK 经常被误解成"非阻塞 IO 的开关"，但从内核角度看，它的含义非常具体，也非常冷酷：
禁止当前 read 调用把进程挂起。

当 file 带有 O_NONBLOCK 标志时，一旦底层对象当前无法提供数据，read 不会进入等待队列，而是立即返回错误。

$!Supplement$
O_NONBLOCK 的真实作用不是"异步"，而是拒绝进入 schedule()。

这就是为什么 read 会返回 -EAGAIN 或 -EWOULDBLOCK。它们不是异常，而是一种显式的控制流信号 ：

"现在不行，但你可以稍后再来"。

3.5 等待发生在哪里：file->f_op->read

真正的等待逻辑，并不写在 vfs_read 里，而是下沉到具体的 file_operations 实现中。

字符设备、socket、pipe、普通文件，各自有不同的 read 实现，但它们都共享一个共识：如果要等，就把当前进程挂到等待队列上。

这一步会涉及：

当前进程状态被置为 TASK_INTERRUPTIBLE
被挂入 file 对应的 wait queue
调用调度器，让出 CPU

直到某个事件（中断、DMA 完成、对端写入）触发唤醒，read 才会继续执行。

反直觉但正确的一点在这里：
read 的"阻塞"，并不是它的默认行为，而是底层对象选择的一条路径。

3.6 errno 的哲学：用返回值描述"世界的状态"

read 返回 -EAGAIN，看起来像错误，实际上却是 Linux IO 模型里极其重要的一环。errno 并不是用来描述"你写错了代码"，而是用来描述系统此刻的客观状态。

在非阻塞语义下，read 没有数据不是异常，而是一种合法结果。内核通过 errno 把"是否需要等待"的决定权，交还给用户态。

$!IMPORTANT$
IO 模型的核心不是把复杂性藏起来，而是把等待的选择权交给调用者。

3.7 所有 IO 模型分支，都从这里分叉

到这里，可以把一条极其重要的结论钉死：

$!NOTE$
Linux IO 模型的所有分支，

------阻塞、非阻塞、多路复用、异步------
全部分叉在"read 要不要等"这个判断点上。

read 是同步接口，这一点从未改变；

是否阻塞，取决于 file 状态；

是否由用户态统一等待，取决于你是否愿意自己管理"什么时候再来"。

3.8 一个自然但危险的问题

如果你已经意识到问题的核心在"等待"，那么一个问题几乎是必然的：

$!Question$
如果我不想在 read 里等，

但又不想不停地 read + EAGAIN 自旋，
内核还能为我做什么？

这个问题，正是 IO 多路复用诞生的动机。

下一章，我们会从"阻塞为什么不可控"开始，把等待语义从单个 read 调用中剥离出来。

4. 阻塞 / 非阻塞 / 同步 / 异步的正确坐标系

内核层次定位：语义模型层（抽象语义 → syscall 行为 → 等待机制的解释框架）

4.1 这一章存在的意义：给 IO 模型"重新定坐标"

如果回顾前面几章，其实一直在刻意回避一个看似基础、却极其危险的问题：
阻塞、非阻塞、同步、异步到底在描述什么？

危险之处不在于它们难，而在于"你以为你懂了"。几乎所有关于 IO 模型的争论，最终都会退化成概念对骂，而不是对内核行为的验证。其根本原因只有一个：把本来正交的语义维度，硬生生压成了一条轴。

这也是为什么必须用一整章，单独把这套概念"拆干净"，否则后面无论讲 select、epoll 还是 io_uring，都会变成在错误地基上的高楼。

4.2 混乱的根源：两个正交维度被混用

Linux IO 语义至少存在两个完全独立的维度：

Block/NBlock：调用线程是否被挂起（Blocking vs Non-blocking）

这是一个调度层问题 ，关心的是当前执行流会不会进入 TASK_INTERRUPTIBLE / TASK_UNINTERRUPTIBLE，会不会被 schedule() 换下 CPU。
Sync/Async：IO 完成责任在谁（Synchronous vs Asynchronous）

这是一个完成路径问题 ，关心的是：

IO 的推进和完成，是由发起调用的线程自己一路做到返回 ，还是交给内核在后台完成，调用点只负责提交请求。

这两个维度彼此独立，却在大量文章中被混为一谈，才催生出"同步 = 阻塞""异步 = 非阻塞"这类经不起推敲的说法。

$!NOTE$
任何关于 IO 模型的判断，只要不回答这两个问题之一，都是不完整的。

4.3 严格二维坐标系：把概念放回该在的位置

如果必须给出一个"最终解释框架"，那么 IO 模型应当被放进如下二维坐标系中理解（文字表格表示）：

线程是否阻塞	IO 完成责任	语义解释
阻塞	用户线程	经典同步阻塞 IO：read/write 默认行为
非阻塞	用户线程	同步非阻塞 IO：O_NONBLOCK + EAGAIN
阻塞	内核	语义上几乎不存在（自相矛盾）
非阻塞	内核	真正的异步 IO 目标形态

这个表格里，前两行是 Linux 长期稳定支持的语义；最后一行，是 Linux 直到 io_uring 才开始真正靠近的目标。

关键在于："同步/异步"描述的是"谁负责完成"，而不是"等不等"。

4.4 同步 API ≠ 阻塞语义：read 是最好的反例

read 是一个同步 API，这是一个事实。它的返回值语义是：

"当我返回时，我已经把这次 read 能给你的结果给完了。"

但 read 是否阻塞，完全取决于 struct file 上的状态，尤其是 f_flags 中是否包含 O_NONBLOCK。

源码层面的锚点非常清晰：

include/linux/fs.h：定义了 file flags、O_NONBLOCK 等标志
fs/read_write.c：vfs_read() 在这里判断是否允许等待

当 O_NONBLOCK 被设置时，vfs_read 在发现"当前无法推进 IO"时，不会进入等待路径，而是立刻返回 -EAGAIN。

$!IMPORTANT$
返回 -EAGAIN 不是失败，而是内核对用户态说：
"我现在不等，你要不要自己想办法？"

这也是为什么说：

同步 API 只是描述"调用与结果的绑定关系"，并不自动意味着阻塞。

4.5 等待发生在何处，才是判据

一切语义纠偏，最终都可以归结为一个可验证的问题：

等待发生在何处？由谁承担？

如果等待发生在发起 read 的线程中，那它就是阻塞的。
如果等待被拒绝（O_NONBLOCK），线程不睡，那就是非阻塞的。
如果等待被转移到内核内部，由其他机制推进，那才谈得上异步。

Linux 传统 IO 的问题恰恰在于：
VFS + 页缓存 + 文件系统路径，天生是"调用线程推进式"的模型。

这直接导致 POSIX AIO 在 Linux 上长期不彻底。

4.6 为什么 Linux 的"文件异步化"如此困难

文件 IO 的 POSIX 异步化，并不是"少写点代码"就能实现的问题。它卡在几个无法回避的设计现实上：

页缓存语义

文件 IO 默认要维护 page cache，一次 read 可能是纯内存拷贝，也可能触发磁盘 IO。异步化意味着缓存一致性、缺页、回写路径都要可延迟处理。
通用 VFS 抽象

VFS 试图对所有文件系统、设备提供统一语义，这使得"后台推进 IO"很难在不破坏抽象的前提下实现。
回写与完成路径

文件 IO 的"完成"并不等于"DMA 结束"，而是涉及元数据更新、页状态切换，这些步骤长期假设在调用线程上下文中执行。

这些约束，决定了 Linux 传统 AIO 更像是"内核线程代你阻塞"，而不是语义上的真正异步。这也是 io_uring 出现的重要背景之一，但这里点到为止。

4.7 等待机制的语义锚点：wait queue

无论阻塞还是非阻塞，Linux 对"等待"的统一抽象，最终都会落到等待队列：

结构体定义位于 include/linux/wait.h
核心概念是 wait_queue_head_t

在阻塞路径中，当前进程会被挂入某个 wait queue，并修改自身状态；在条件满足时，由事件源唤醒。

$!NOTE$
等待队列不是实现细节，而是 IO 模型的"力学基础"。

这一点，是下一篇的绝对主线。

4.8 面试高频纠偏清单

$!TIP$
1）"非阻塞就是异步"错在哪？

非阻塞只是"不让我睡"，并没有把 IO 推进责任交给内核。

2）"epoll 是异步 IO"错在哪？

epoll 只是集中等待，read 仍然是同步推进。

3）"同步 IO 一定阻塞"错在哪？

O_NONBLOCK 直接否定了这个等式。

4）"io_uring = epoll + 线程池"错在哪？

io_uring 的关键不在等，而在内核接管推进路径。

4.9 语义漂移考古：asynchronous 到底在说谁

$!Supplement$
在硬件层，asynchronous 往往指 DMA 不占用 CPU；

在内核层，指提交与完成解耦；

在用户 API 层，却常被误用为"调用不阻塞"。

这三者并不等价，混用必然导致理解错位。

最小对照示例如下：

c 复制代码

int fd = open(...);

// 阻塞同步
read(fd, buf, n);

// 非阻塞同步
fcntl(fd, F_SETFL, O_NONBLOCK);
if (read(fd, buf, n) < 0 && errno == EAGAIN) {
    // 没等，直接返回
}

这里没有任何"异步"，只有"等不等"。

4.10 为什么"等待"是操作系统的永恒主题

从批处理系统的作业队列，到分时系统的进程调度，再到网络时代的 C10K，本质上都在解决同一件事：
如何在有限 CPU 下，管理大量"尚未就绪"的任务。

IO 模型之所以在网络时代被重新发明，并不是因为旧模型"错误"，而是因为等待规模发生了数量级变化。

4.11 承上启下：下一步必须直面"等待本身"

走到这里，你已经具备了一套稳定的语义坐标系 。

你知道哪些说法是偷换概念的，也知道判断 IO 模型优劣的判据是什么。

但有一个问题依然悬空：
等待在内核中究竟是如何发生的？

阻塞意味着什么状态切换？

进程是如何被挂起、如何被唤醒？

可中断等待与不可中断等待的差异在哪里？

下一篇，将彻底进入实现核心，拆解阻塞 / 非阻塞 IO 的底层机制：

从进程状态、睡眠队列，到唤醒路径与调度点。

点击阅读下一篇：
# Linux IO 模型纵深解析 02：阻塞 IO 与非阻塞 IO