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

在 Linux 世界里，fd 是最容易被忽略的存在。

它只是一个 int，没有类型信息、没有状态、没有语义，看起来像是早期 Unix 遗留下来的"简陋接口"。

但正是这个不起眼的整数，串起了用户态与内核态之间几乎所有 I/O 行为：文件、socket、管道、epoll、timerfd，乃至事件与资源回收。

如果只把 fd 当作"文件描述符"，很多内核层面的行为都会显得反直觉。

真正理解 fd，意味着你必须从系统调用一路下钻，走进 struct file、引用计数和事件机制的世界。

Key Words:

#Linux内核 #FileDescriptor #VFS #struct_file

#epoll #files_struct #系统调用 #内核对象模型

文章目录

- [0. fd 不是文件，这是理解 Linux I/O 的第一道门](#0. fd 不是文件，这是理解 Linux I/O 的第一道门)
- [1. 用户态眼中的 fd：一个被严重低估的 int](#1. 用户态眼中的 fd：一个被严重低估的 int)
- - [1.1 fd 在 API 里的角色定位](#1.1 fd 在 API 里的角色定位)
  - [1.2 fd 与"文件"的常见误解](#1.2 fd 与“文件”的常见误解)
  - [1.3 为什么 fd 必须是 int，而不是指针或句柄对象](#1.3 为什么 fd 必须是 int，而不是指针或句柄对象)
  - [1.4 用户态这一层，Linux 刻意让你"看不见"](#1.4 用户态这一层，Linux 刻意让你“看不见”)
- [2. fd 在内核中的真正归属：task_struct → files_struct](#2. fd 在内核中的真正归属：task_struct → files_struct)
- - [2.1 从 current 出发：fd 不属于系统，只属于进程](#2.1 从 current 出发：fd 不属于系统，只属于进程)
  - [2.2 task_struct 里的 files：为什么 fd 管理权在这里](#2.2 task_struct 里的 files：为什么 fd 管理权在这里)
  - [2.3 files_struct：进程的 fd 命名空间](#2.3 files_struct：进程的 fd 命名空间)
  - [2.4 fdtable：fd → struct file 的真正映射层](#2.4 fdtable：fd → struct file 的真正映射层)
  - [2.5 为什么 fd 是 per-process，而不是 per-thread](#2.5 为什么 fd 是 per-process，而不是 per-thread)
  - [2.6 小结式锚点：fd 在内核的第一落点](#2.6 小结式锚点：fd 在内核的第一落点)
- [3. fd 指向的核心对象：struct file 的职责边界](#3. fd 指向的核心对象：struct file 的职责边界)
- - [3.1 一个容易被误解的事实：file 不是"文件"](#3.1 一个容易被误解的事实：file 不是“文件”)
  - [3.2 file 为什么必须存在：VFS 的"最小统一抽象"](#3.2 file 为什么必须存在：VFS 的“最小统一抽象”)
  - [3.3 f_pos：为什么文件偏移放在 file，而不是 inode](#3.3 f_pos：为什么文件偏移放在 file，而不是 inode)
  - [3.4 f_op：fd 能"读一切"的真正原因](#3.4 f_op：fd 能“读一切”的真正原因)
  - [3.5 file 的生命周期：fd close 并不等于 file 消亡](#3.5 file 的生命周期：fd close 并不等于 file 消亡)
  - [3.6 file、inode、dentry：三者的职责边界](#3.6 file、inode、dentry：三者的职责边界)
  - [底层延伸思考（通往第 4 章）](#底层延伸思考（通往第 4 章）)
- [4. open() 全链路：fd 是在哪一步诞生的](#4. open() 全链路：fd 是在哪一步诞生的)
- - [4.1 从用户态 open() 开始：真正重要的不是路径字符串](#4.1 从用户态 open() 开始：真正重要的不是路径字符串)
  - [4.2 syscall 入口：open 并不直接干活](#4.2 syscall 入口：open 并不直接干活)
  - [4.3 do_filp_open：file 的诞生点](#4.3 do_filp_open：file 的诞生点)
  - [4.4 file 在这里是"打开行为的证明"](#4.4 file 在这里是“打开行为的证明”)
  - [4.5 fd 的分配：get_unused_fd 的真实角色](#4.5 fd 的分配：get_unused_fd 的真实角色)
  - [4.6 fd_install：fd 与 file 的正式绑定](#4.6 fd_install：fd 与 file 的正式绑定)
  - [4.7 为什么 fd 一定在最后才分配](#4.7 为什么 fd 一定在最后才分配)
  - [4.8 一条完整的调用链，背后的设计取舍](#4.8 一条完整的调用链，背后的设计取舍)
  - [底层延伸思考（通往第 5 章）](#底层延伸思考（通往第 5 章）)
- [5. dup / fork：fd 复制的真正含义](#5. dup / fork：fd 复制的真正含义)
- - [5.1 一个必须先打掉的误区：dup ≠ 打开新文件](#5.1 一个必须先打掉的误区：dup ≠ 打开新文件)
  - [5.2 dup 在内核里到底复制了什么](#5.2 dup 在内核里到底复制了什么)
  - [5.3 fork：比 dup 更"危险"的共享](#5.3 fork：比 dup 更“危险”的共享)
  - [5.4 为什么 fork 不立刻复制 fdtable](#5.4 为什么 fork 不立刻复制 fdtable)
  - [5.5 fork 之后，父子进程如何"各自修改 fd"](#5.5 fork 之后，父子进程如何“各自修改 fd”)
  - [5.6 file 的引用计数：共享语义的真正支点](#5.6 file 的引用计数：共享语义的真正支点)
  - [5.7 一个极其重要的并发语义：共享 f_pos](#5.7 一个极其重要的并发语义：共享 f_pos)
  - [5.8 Linux 为什么不"帮你复制一个新 file"](#5.8 Linux 为什么不“帮你复制一个新 file”)
  - [5.9 小结式锚点：fd 复制从来不是"拷贝资源"](#5.9 小结式锚点：fd 复制从来不是“拷贝资源”)
  - [底层延伸思考（通往第 6 章）](#底层延伸思考（通往第 6 章）)
- [6. close(fd)：到底关闭了什么](#6. close(fd)：到底关闭了什么)
- - [6.1 close 的第一刀：从 fdtable 里"拔掉"这个下标](#6.1 close 的第一刀：从 fdtable 里“拔掉”这个下标)
  - [6.2 为什么要先拔 fd 再 fput：这是并发语义，不是代码习惯](#6.2 为什么要先拔 fd 再 fput：这是并发语义，不是代码习惯)
  - [6.3 fput：close 的"第二阶段"，也是最关键的分水岭](#6.3 fput：close 的“第二阶段”，也是最关键的分水岭)
  - [6.4 file 到底长什么样：哪些字段决定 close 行为](#6.4 file 到底长什么样：哪些字段决定 close 行为)
  - [6.5 `__fput` 的释放路径：从 VFS 到具体文件系统/设备](#6.5 __fput 的释放路径：从 VFS 到具体文件系统/设备)
  - [6.6 close 与 "数据是否落盘"：别用 close 承担 fsync 的语义](#6.6 close 与 “数据是否落盘”：别用 close 承担 fsync 的语义)
  - [6.7 最阴的坑：close 的 fd 复用与竞态](#6.7 最阴的坑：close 的 fd 复用与竞态)
  - [6.8 close 与 epoll/io_uring：为什么你关了 fd 事件还在](#6.8 close 与 epoll/io_uring：为什么你关了 fd 事件还在)
  - [6.9 close() 一句话](#6.9 close() 一句话)
  - [底层延伸思考（通往第 7 章）](#底层延伸思考（通往第 7 章）)
- [7. fd 与 epoll：事件系统为什么必须绕开 fd](#7. fd 与 epoll：事件系统为什么必须绕开 fd)
- - [7.1 先把问题说死：fd 在事件系统里是不合格的锚点](#7.1 先把问题说死：fd 在事件系统里是不合格的锚点)
  - [7.2 epoll 的第一步：通过 fd 找到真正的锚点](#7.2 epoll 的第一步：通过 fd 找到真正的锚点)
  - [7.3 epitem：epoll 内部真正的事件实体](#7.3 epitem：epoll 内部真正的事件实体)
  - [7.4 epoll 真正监听的不是 file，而是 file 背后的等待队列](#7.4 epoll 真正监听的不是 file，而是 file 背后的等待队列)
  - [7.5 事件是如何"主动送到 epoll"的](#7.5 事件是如何“主动送到 epoll”的)
  - [7.6 为什么 close(fd) 之后，epoll 仍然"活着"](#7.6 为什么 close(fd) 之后，epoll 仍然“活着”)
  - [7.7 epoll 为什么天然规避 fd 复用问题](#7.7 epoll 为什么天然规避 fd 复用问题)
  - [7.8 select / poll 与 epoll 的根本分水岭](#7.8 select / poll 与 epoll 的根本分水岭)
  - [7.9 本章落点](#7.9 本章落点)
- [8. fd 的边界：上限、泄漏与系统级后果](#8. fd 的边界：上限、泄漏与系统级后果)
- - [8.1 先给一个总览：fd 的限制不是一层，而是三层叠加](#8.1 先给一个总览：fd 的限制不是一层，而是三层叠加)
  - [8.2 第一层：进程级 fd 上限（RLIMIT_NOFILE）](#8.2 第一层：进程级 fd 上限（RLIMIT_NOFILE）)
  - [8.3 第二层：系统级 file 对象上限（fs.file-max）](#8.3 第二层：系统级 file 对象上限（fs.file-max）)
  - [8.4 为什么系统级 file 上限一定存在](#8.4 为什么系统级 file 上限一定存在)
  - [8.5 第三层：真正的杀手------内核内存与对象链条](#8.5 第三层：真正的杀手——内核内存与对象链条)
  - [8.6 为什么 fd 泄漏比 malloc 泄漏更危险](#8.6 为什么 fd 泄漏比 malloc 泄漏更危险)
  - [8.7 ulimit 调大了，为什么还是 "Too many open files"](#8.7 ulimit 调大了，为什么还是 “Too many open files”)
  - [8.8 fd 上限的本质：限制的是"可达性"，不是"能力"](#8.8 fd 上限的本质：限制的是“可达性”，不是“能力”)
  - 底层延伸思考（为全文收尾埋点）
- [THE END](#THE END)
- - [fd 是一种"受控访问权"，而不是资源本体](#fd 是一种“受控访问权”，而不是资源本体)
  - "一切皆文件"，本质是对复杂度的极端压缩
  - [fd 设计本质是高内聚低耦合](#fd 设计本质是高内聚低耦合)
  - 写在最后

0. fd 不是文件，这是理解 Linux I/O 的第一道门

刚接触 Linux I/O 的时候，很容易把 fd 当成"文件本身"，或者至少当成"文件的身份证"。

这种理解写 demo 没问题，但一旦开始碰多进程、socket、epoll、重定向，很快就会发现解释不通。

同一个 fd，在不同进程里意义完全不同。
close(fd) 了，对端却还没断。

fork 之后父子进程读同一个文件，偏移会互相影响。
dup2 一行代码就能把 stdout 换个去向。

这些现象表面看起来很零散，但背后其实只有一个核心问题：

fd 到底是不是"文件"？

答案很明确：不是。

在 Linux 里，fd 只是进程视角下的一个索引编号 。

内核并不关心"fd 等于几"，它只关心：

这个进程，通过这个编号，最终找到了哪个内核对象。

真正承载 I/O 行为的，从来不是 fd，而是 fd 背后那一整套对象关系。

$!NOTE$
fd 不是资源，只是钥匙。

资源在内核里，fd 只负责"找到它"。

理解这一点之后，很多之前靠"死记结论"的东西会突然连起来：

为什么 read/write 能同时操作文件、管道、socket

为什么 fork / dup 会共享偏移和状态

为什么 epoll 监听的是 fd，却在内核里维护另一套结构

为什么 close 了 fd，不一定立刻释放资源

这篇文章不会一上来讲 VFS、inode、dentry 的定义。

而是先把这套 "fd → 内核对象 → 行为发生点" 的世界观立住，再逐层往下拆。

如果你在读后面的章节时，脑子里始终有一句话在兜底：

"fd 只是入口，不是本体"

那这一章的目的就达到了。

1. 用户态眼中的 fd：一个被严重低估的 int

【用户态】

1.1 fd 在 API 里的角色定位

在用户态写程序时，fd 的存在感低到几乎透明。
open() 返回一个 int，read()、write()、close() 把这个 int 原样塞回去，函数签名干净得近乎敷衍：

c 复制代码

int fd = open("a.txt", O_RDONLY);
read(fd, buf, size);
close(fd);

但正是这种"毫无特色"，掩盖了 fd 在 Linux I/O 模型中的真实地位。

fd 是 Linux 在用户态暴露的 唯一统一 I/O 入口 。

文件、管道、socket、eventfd、signalfd，用户态一概不需要关心它们背后是磁盘、网卡还是内核对象，全部通过同一套 syscall 接口进内核。

这不是语法糖，而是一个极端强约束的设计选择 ：用户态不允许直接持有任何内核对象引用。

fd 的"值"没有任何物理意义。

它不编码类型，不携带地址信息，也不暗示资源位置。它唯一的语义是：

"在当前进程的上下文里，第 N 个被占用的入口。"

这也是为什么你永远不能把一个 fd 从 A 进程直接传给 B 进程用------
fd 的解释权只存在于进程内部。

1.2 fd 与"文件"的常见误解

fd 最常见、也最致命的误解只有一句话：

"fd 就是文件。"

这个误解会在你第一次写多进程、多线程、epoll、fork 程序时反噬你。

在用户态语义里，"文件"是一个过于宽泛的词。

但在内核设计中，"文件"至少被拆成了三层不同的概念，而 fd 一层都不直接对应：

fd 不是磁盘文件
fd 不是 inode
fd 甚至不是 socket

fd 在用户态只是一个 名字空间中的编号 ，类似数组下标，但比数组更严格：

你既不能对它做指针运算，也不能窥探它背后的结构。

这也是 Linux 和某些微内核路线的根本差异之一：

Linux 拒绝在用户态暴露任何"半透明"的内核句柄。

$!NOTE$
fd 的存在不是为了方便，而是为了隔离与约束。

只要你还在用户态，fd 的使命就只有一个：
作为参数，把控制权安全地送进内核。

至于这个 int 在内核里会引发怎样的结构跳转、引用计数变化、锁竞争------

用户态被刻意设计成无从得知。

1.3 为什么 fd 必须是 int，而不是指针或句柄对象

这个问题在面试里很少被直接问，但它决定了你对 Linux 抽象层次的理解深度。

如果 fd 是一个指针，会发生什么？

用户态就能推断内核地址空间布局
ASLR 直接失效一半
内核对象生命周期暴露给用户态
copy_to_user / copy_from_user 的边界变得模糊

Linux 从一开始就选择了最"粗暴"的方案：
fd 只是一个整数，下标语义，没有任何可推断性。

更重要的是，int fd 这个形式，天然绑定了一个事实：
fd 的解释必须依赖"当前进程"这个隐式上下文。

这为后面的一切设计埋下了伏笔：

fork 为什么能继承 fd
dup 为什么能共享偏移
close 为什么不一定释放资源

这些行为在用户态看起来"奇怪"，但在内核视角里都极其自然。
$!SUPPLEMENT\] 什么是 ASLR？ **ASLR (Address Space Layout Randomization，地址空间布局随机化)** 是一种关键的计算机安全技术，旨在防止攻击者利用内存破坏漏洞（如缓冲区溢出）。$

1.4 用户态这一层，Linux 刻意让你"看不见"

如果你只停留在用户态，fd 的设计甚至显得有点"偷懒"：

没有类型系统，没有对象模型，没有方法表。

但这正是 Linux 的态度：
用户态不参与资源管理决策，只负责发请求。

fd 的所有"智能"，全部发生在 syscall 之后。

也正因为如此，

你在用户态看到的 fd 越"简单"，内核里那套机制就越复杂、越值得拆。

2. fd 在内核中的真正归属：task_struct → files_struct

【用户态 → 内核态切换点】

2.1 从 current 出发：fd 不属于系统，只属于进程

一旦系统调用发生，视角立刻切换。

在内核里，fd 不再是那个"随手传进来的 int"，

它的解释权来自一个隐式但绝对的前提：当前正在运行的进程是谁。

这个入口只有一个------current。

current 指向当前 CPU 上正在运行的 task_struct，

而 fd 的全部语义，都被挂在这个结构体的资源体系之下。

这一步非常关键：
Linux 从未设计过"全局 fd"。

哪怕系统里有一百万个打开的文件，

fd 的编号空间依然是 按进程隔离的 ，每个进程都从 0、1、2 往上数。

这也是为什么两个进程里同时存在 fd=3，内核不会产生任何歧义。

!TIP
current 在内核里"看起来像变量"，其实是个架构相关的宏 ：它的核心思路不是查表，而是利用当前内核栈指针 反推出当前任务。

这本身是 Linux 进程控制相关的一部分，在这里提一下。其实目前只需要知道 current 宏是效率极快的通过获取当前 CPU %esp 寄存器的值，反推基址

下面这段就是 Linux 2.6.0 在 i386 上常见的实现套路（current 最终落到 current_thread_info()->task）：
c 复制代码
/* Linux 2.6.0 (i386) 典型实现链路：current -> get_current() -> current_thread_info() */
static inline struct thread_info *current_thread_info(void)
{
    struct thread_info *ti;
    __asm__("andl %%esp,%0" : "=r"(ti) : "0"(~8191UL));
    return ti;
}

static inline struct task_struct *get_current(void)
{
    return current_thread_info()->task;
}

#define current get_current()
读这段代码要抓住一个结论：~8191UL 等价于把栈指针的低 13 位清零，

也就是把 esp 对齐到 8KB 内核栈的栈底------而 thread_info 就贴在那儿。

所以 current 能做到"几乎零成本"，也就解释了为什么内核里到处敢写 current->files。

那 thread_info 和 task_struct 有什么关系呢？

thread_info 结构体内含一个 task_struct *task 用于指向当前线程的 task_struct

而一些架构下 task_struct 也会反指 thread_info :（参考# Linux进程内核栈与thread_info结构详解--Linux进程的管理与调度（九）)
C 复制代码
struct task_struct 
{ 
// ... 
	void *stack; // 指向内核栈的指针 拿到栈底就是 thread_info 的起始地址
// ... 
};
一般的访问路径：

syscall / 中断发生

CPU 切到 当前任务的内核栈

%esp 落在这块 8KB 栈里

esp & ~(THREAD_SIZE-1) → thread_info

thread_info->task → task_struct

current->files → fdtable

2.2 task_struct 里的 files：为什么 fd 管理权在这里

在 task_struct 中，fd 相关的一切，集中在一个字段上：

c 复制代码

struct task_struct {
    ...
    struct files_struct *files;
    ...
};

这一行决定了 fd 的归属模型。

Linux 把 fd 明确划为 "进程级资源" ，而不是线程级、系统级。

这背后的设计动机非常现实：

fd 需要随 fork 继承
fd 需要随 exit 自动回收
fd 需要参与权限与安全边界

如果 fd 脱离 task_struct，这三点都会变得极其别扭。

而 files_struct 的存在，本质上是在说一句话：
"一个进程，对外界能看到什么资源，全在这里。"

2.3 files_struct：进程的 fd 命名空间

真正存放 fd 信息的，不是 task_struct，而是 files_struct。

它不是一个简单的数组，而是一个被锁、被引用计数、可共享的资源容器。

在结构设计上，files_struct 解决的是三个问题：

fd 的编号空间如何组织
fork/dup 时 fd 如何共享
并发访问 fd 时如何加锁

核心字段不会逐个列，但有两个概念必须讲透：
引用计数 和 fdtable。

files_struct 本身是可以被多个 task 共享的。

这就是为什么 fork 之后，父子进程在一开始看到的是同一套 fd。

$!NOTE$
fork 并不复制 fdtable，而是先共享 files_struct。

这个设计直接避免了 fork 时 O(n) 复制 fd 的开销，

而真正的复制，发生在 写时复制（COW, copy-on-write 又是也叫写时拷贝） 那一刻。

2.4 fdtable：fd → struct file 的真正映射层

fd 并不是直接存在 files_struct 里的。

files_struct 内部维护的是一个指向 fdtable 的指针，

而 fdtable 才是那个"看起来像数组"的东西。

fdtable 的职责非常单一，却极其关键：

把一个小整数 fd，映射到一个 struct file *。

这里的"像数组"，并不意味着它真的可以随便扩展。

fdtable 的设计，体现了 Linux 对性能和内存的双重妥协：

小 fd 使用内嵌表，避免频繁分配
fd 增多时才动态扩容
查找 fd 必须是 O(1)

这也是为什么 fd 被强制设计为整数索引，

而不是哈希、树或对象句柄。

fd 的访问路径必须极短，因为它出现在几乎所有 I/O 系统调用中。

2.5 为什么 fd 是 per-process，而不是 per-thread

这是一个隐藏得很深、但极其重要的设计选择。

Linux 的线程，本质上仍然是 task_struct，

但它们可以 共享 files_struct。

这意味着：

同一进程内的多线程，默认共享 fd
close(fd) 影响的是整个进程，而不是某个线程
fd 的并发访问，必须由内核保证安全

如果 fd 是线程私有的，

用户态几乎无法正确实现多线程 I/O 协作。

这也是为什么你在多线程程序里关闭 fd 时，

一不小心就能把另一个线程的 I/O 干死。

$!Question$
多线程环境下，一个线程 close(fd)，另一个线程正在 read，会发生什么？

这个问题的答案，完全取决于你是否理解
fd 是 files_struct 级别的资源。

2.6 小结式锚点：fd 在内核的第一落点

到这里，fd 的第一层真相已经明确：

fd 不存在于系统层
fd 不直接存在于 task_struct
fd 通过 files_struct 间接存在
fd 只是 fdtable 的索引

fd 从用户态到内核的第一次"解包"，

就在 task_struct → files_struct → fdtable 这条链路上完成。

3. fd 指向的核心对象：struct file 的职责边界

【内核态 · VFS 核心层】

到这一章，fd 这条线必须发生一次视角升级。

前两章我们已经确认了一件事：

fd 在内核里只是 files_struct->fdtable 的一个索引。

索引本身不携带任何 I/O 语义，真正决定"读什么、怎么读、从哪读"的，是它指向的那个对象。

这个对象，就是 struct file。

3.1 一个容易被误解的事实：file 不是"文件"

struct file 的名字极具迷惑性。

如果你从用户态直觉出发，很容易以为：

file 就是文件，inode 是文件元数据，fd 指向 file，三者层层递进。

但在内核设计里，file 从来不是"文件本体"。

更准确的说法是：

struct file 描述的是"一次打开行为"，而不是一个持久存在的对象。

这句话的分量很重。

内存上描述磁盘上的文件 → inode
描述文件系统中的目录项 → dentry
某个进程执行一次 open() → 生成一个新的 struct file

也就是说：
file 是 runtime 对象，inode 是持久对象。

这也是为什么：

同一个 inode，可以同时对应多个 file
不同进程 open() 同一个路径，得到的是不同的 file
但这些 file 又可以共享同一个 inode

这一层拆开，后面所有 fd 行为才解释得通。

3.2 file 为什么必须存在：VFS 的"最小统一抽象"

如果站在 VFS 设计者的视角，struct file 解决的是一个极其现实的问题：

如何让 read/write 这类系统调用，
不关心底层到底是 ext4、pipe 还是 socket？

答案就是：
把"本次 I/O 操作的上下文"收敛进一个统一结构。

struct file 正是这个"上下文容器"。

它至少承担三类职责：

状态容器 ：

文件偏移、打开标志、访问模式
能力入口 ：

通过 f_op 间接调用具体实现
生命周期锚点 ：

引用计数，决定何时真正释放

注意，这三点里，没有一条是 inode 能干的。

3.3 f_pos：为什么文件偏移放在 file，而不是 inode

这是一个非常经典、也非常能区分"看过源码"和"只背概念"的问题。

答案其实只需要一句话：

文件偏移属于"这次打开"，而不是"这个文件"。

如果偏移存在 inode 里，会发生什么？

两个进程同时 read 同一个文件
进程 A 读完 100 字节
进程 B 再读，发现偏移已经被推进

这在语义上是不可接受的。

于是 Linux 把 f_pos 放在 struct file 里，

让"偏移"成为 打开实例级别的状态。

这也解释了另一个经常让人困惑的现象：

dup() 之后，两个 fd 会共享文件偏移。

因为它们指向的是 同一个 struct file。

3.4 f_op：fd 能"读一切"的真正原因

fd 之所以能对文件、管道、socket 一视同仁，

核心并不在 fd，而在 struct file 里的这一行：

c 复制代码

const struct file_operations *f_op;

f_op 是 VFS 的多态入口。

当你在用户态调用：

c 复制代码

read(fd, buf, size);

内核里的调用链是：

复制代码

sys_read
  -> vfs_read
     -> file->f_op->read

至此，fd 已经彻底退出舞台。

真正决定行为的是：

这个 file 对应的 f_op 是哪一套
read 指针指向哪个实现

对于普通文件，它可能落到 ext4；

对于 socket，它会跳到 net 子系统；

对于 pipe，它会进入 pipe 缓冲区逻辑。

$!NOTE$
VFS 的统一，并不是"统一数据结构"，

而是统一"调用入口 + 语义契约"。

3.5 file 的生命周期：fd close 并不等于 file 消亡

struct file 是一个带引用计数的对象。

这意味着：

fd close：减少一次引用
dup / fork：增加引用
真正释放：等引用计数归零

所以你在代码里看到的：

c 复制代码

close(fd);

在内核里的真实语义是：

解除 fd → file 的绑定，而不是立刻销毁 file。

这也是为什么：

fork 后，父子进程可以安全共享 file
epoll 可以在 fd close 后仍然"感知到事件变化"
延迟释放成为可能

file 是 fd 与底层对象之间的缓冲层 ，

也是 Linux I/O 能玩出这么多花样的基础。

3.6 file、inode、dentry：三者的职责边界

到这里，有必要把这三个对象的边界彻底划清：

inode ：

描述"这是哪个文件"，偏向持久语义
dentry ：

描述"这个路径名如何解析到 inode"
file ：

描述"某个进程的一次打开行为"

fd 只关心 file。

file 再去关心 inode 和 dentry。

这也是为什么：

unlink 不一定影响已打开的 fd
rename 不会改变 file 的行为
文件被删除后，仍可继续 read/write

所有这些"反直觉行为"，

都只是 file 这一层抽象的自然结果。

底层延伸思考（通往第 4 章）

现在我们已经明确：

fd → struct file
file 承载 I/O 状态与能力
inode 承载持久语义

那下一个问题就非常自然了：

file 是在什么时候被创建的？
fd 又是在什么时候与它绑定的？

也就是说：
open() 这一次系统调用，在内核里到底干了哪些事？

下一章，我们不再停留在结构体层面，

而是沿着一条完整的 syscall 路径，把 open() 从入口一路追到 fd 安装完成。

4. open() 全链路：fd 是在哪一步诞生的

【用户态 → syscall → VFS → fdtable】

到这一章，fd 这条主线已经具备了所有前置条件。

我们知道 fd 不重要，file 才重要；

我们也知道 fd 属于 current->files，而不是系统全局。

现在的问题只剩一个：

一次 open()，内核里究竟发生了什么？
fd 是"顺手分配的"，还是某个阶段的必然产物？

4.1 从用户态 open() 开始：真正重要的不是路径字符串

在用户态，open() 看起来像一个以路径为中心的操作：

c 复制代码

int fd = open("/tmp/a.txt", O_RDONLY);

但一旦进入内核，路径反而不是重点 。

路径只是一个输入参数，它的使命在 VFS 路径解析阶段就基本结束了。

真正贯穿整个 open 流程的主线，其实是两件事：

能否成功构造一个 struct file
能否为它分配一个 fd 并挂进当前进程

路径，只是用来"找到 inode 的手段"。

4.2 syscall 入口：open 并不直接干活

在 Linux 2.6 及其后续版本中，用户态的 open() 会走到类似这样的入口：

复制代码

sys_open / sys_openat

这一层的特点只有一个：
几乎不做任何实质性工作。

它的职责非常克制：

从用户态拷贝参数
做最基本的合法性检查
把控制权交给 VFS 层

这是 Linux syscall 设计的共性：
sys 函数不是"业务逻辑层"，而是"边界层"。_*

真正的 open 语义，不在这里。

4.3 do_filp_open：file 的诞生点

open 这条链路的第一个关键拐点，是：

复制代码

do_filp_open

这一步开始，内核的注意力不再放在 fd 上，而是转向一个更重要的目标：

构造一个合法、完整、可用的 struct file。

在这一阶段，内核完成了几件决定性的事情：

路径解析（namei）
权限检查
inode 与 dentry 的确定
文件系统相关的 open 回调

只有当这些步骤全部成功，

内核才会认为：

"这次 open 行为，在语义上是成立的。"

这也是一个非常重要的设计信号：
Linux 先保证 file 的语义正确性，再谈 fd 的分配。

4.4 file 在这里是"打开行为的证明"

在 do_filp_open 返回时，一个 struct file * 已经存在了。

注意这个时间点：
此时还没有 fd。

这说明一个事实：

fd 并不是 open 的核心目标，

它只是"把 file 暴露给用户态的一种方式"。

在内核看来，真正有意义的是：

"我是否成功构造了一个 file 对象"。

fd 只是接下来要解决的"编号问题"。

4.5 fd 的分配：get_unused_fd 的真实角色

file 构造完成后，open 流程才会进入 fd 相关逻辑。

这里的关键步骤是：

复制代码

get_unused_fd_flags

这一步做的事情非常"朴素"，但意义重大：

在 current->files->fdtable 中
找到一个未被占用的下标
确保不超过进程 fd 上限
必要时扩容 fdtable

这一步 完全是进程视角的操作 ，

它不关心 file 是什么类型，也不关心 inode。

这再次印证了一点：

fd 是"进程资源管理"的产物，而不是文件系统的产物。

4.6 fd_install：fd 与 file 的正式绑定

真正把 fd 和 file 绑定在一起的，是这一步：

复制代码

fd_install(fd, file)

这一步非常值得强调，因为它清晰地划定了职责边界：

VFS 负责构造 file
files_struct 负责管理 fd
fd_install 只是把二者"连上线"

此时，内核完成了一件非常关键的事：

把一个"内核对象指针"，安全地映射成一个"用户态整数"。

从这一刻起：

用户态只看到 fd
内核通过 fdtable 找到 file
file 再决定 I/O 行为

fd 的使命正式开始。

4.7 为什么 fd 一定在最后才分配

这一点，是 open 设计中最"工程化"的选择之一。

如果反过来，先分配 fd，再构造 file，会发生什么？

file 构造失败时，需要回滚 fd
fd 可能短暂暴露无效状态
错误路径复杂度暴涨

Linux 的选择是：

先把最复杂、最可能失败的事情做完，
最后才做最简单、最确定的绑定。

这也是 open 流程里 fd 分配位置如此靠后的根本原因。

4.8 一条完整的调用链，背后的设计取舍

把整条链路压缩成一行，就是：

复制代码

sys_open
  -> do_sys_open
     -> do_filp_open   // 构造 struct file
     -> get_unused_fd  // 分配 fd
     -> fd_install     // fd → file

这条链路的设计，非常清楚地体现了 Linux 的思路：

file 是语义核心
fd 是进程视角的映射
二者通过 files_struct 解耦

这也是为什么后续的：

dup
fork
epoll
close

都能围绕 file 玩出复杂而一致的行为。

底层延伸思考（通往第 5 章）

现在我们已经明确：

fd 是在 open 的末尾才出现的
file 的生命周期可以独立于 fd
files_struct 是 fd 管理的真正核心

那接下来的问题就非常自然了：

如果多个 fd 指向同一个 file，
内核是如何保证语义一致性的？

也就是说：

dup 到底复制了什么？
fork 之后 fd 为什么能共享？
file 的引用计数如何支撑这一切？

下一章，我们会专门把 open 的"结果"拆开，

去看 fd 复制与 file 共享 这件事。

5. dup / fork：fd 复制的真正含义

【内核态 · 资源共享与引用语义】

到这一章，fd 这条主线必须面对一个绕不开的现实问题：

Linux 为什么敢让多个 fd，甚至多个进程，
指向同一个 struct file？

这是 fd 设计中最容易被误解、也最容易出 bug 的地方。

理解不清楚这一章，前面讲的 file / f_pos / f_op 都只是表层的概念理清楚。

5.1 一个必须先打掉的误区：dup ≠ 打开新文件

在用户态，dup() 看起来很像一次"再打开"：

c 复制代码

int fd2 = dup(fd1);

但在内核里，这个理解是完全错误的。

dup 不会：

重新解析路径
创建新的 inode 关联
构造新的 struct file

它做的事情只有一件：

在 fdtable 里，再放一个指向"同一个 struct file"的索引。

换句话说：

fd1 → file A
fd2 → file A

二者之间不存在"父子关系"，

它们是平等的入口。

5.2 dup 在内核里到底复制了什么

如果从内核视角描述 dup，可以极端简化成一句话：

复制的是 fdtable 项，而不是 file 本身。

内核做的事情非常克制：

在当前 files_struct->fdtable 中
找一个新的空闲 fd
让这个 fd 指向原来的 struct file *
对 file 的引用计数 +1

整个过程中：

file 的内容不变
inode 不变
f_pos 不变
f_op 不变

这也是为什么 dup 后两个 fd 的文件偏移是共享的。

这不是"副作用"，而是必然结果。

5.3 fork：比 dup 更"危险"的共享

如果说 dup 是"显式共享"，

那 fork 就是 默认共享。

在 fork 发生时，内核对 fd 的处理策略是：

父子进程初始共享同一个 files_struct。

注意这个措辞：

不是"复制 fdtable"，而是共享 files_struct。

这一步极其关键。

5.4 为什么 fork 不立刻复制 fdtable

原因只有一个：
性能。

一个进程可能打开上千个 fd，

如果 fork 时全部复制 fdtable：

O(n) 成本
cache 污染
完全没必要

Linux 的选择是：

先共享，等需要修改时再分离。

这正是 fd 维度的 copy-on-write 思想。

5.5 fork 之后，父子进程如何"各自修改 fd"

fork 之后，父子进程：

指向同一个 files_struct
fdtable 也是同一份
file 引用计数已经正确增加

直到其中一个进程发生这些行为之一：

close(fd)
dup(fd)
打开新文件

这时内核才会触发：

files_struct 的写时复制（copy-on-write）

也就是说：

原来的 files_struct 被"拆开"
当前进程得到一份私有副本
另一个进程不受影响

这一步保证了两个目标同时成立：

fork 足够快
fd 语义依然正确

5.6 file 的引用计数：共享语义的真正支点

无论是 dup 还是 fork，

最终能兜住语义一致性的，只有一个机制：

struct file 的引用计数。

只要还有任意一个 fd 指向这个 file：

file 就不会被释放
f_op 仍然有效
底层资源保持打开状态

而 close(fd) 的真实语义是：

减少一次 file 的引用计数，而不是"关闭文件"。

只有当引用计数归零时：

file 才会被真正销毁
inode 的使用计数才可能减少
底层设备才有机会被释放

5.7 一个极其重要的并发语义：共享 f_pos

现在回到一个经常被低估的问题：

多个 fd / 多个进程同时 write 同一个 file，会发生什么？

答案取决于一个关键事实：

它们是否共享同一个 struct file。

如果共享同一个 file

→ 共享 f_pos

→ write 会推进同一个偏移
如果是不同 file（两次 open）

→ 各自维护 f_pos

→ 偏移互不影响

这也是为什么：

dup + write 可能"交错输出"
fork + write 可能"看起来乱序"

这不是 bug，而是 共享语义的直接体现。

$!Question$
父子进程 fork 后同时 write 同一个 fd，

为什么即使没有显式共享内存，也会产生竞争效果？

因为fork后fd本质指向的是内核的同一个 struct file* 本身也算是隐式共享内存。他们共享 f_pos 字段那么即便 write 系统调用有用 inode 锁来防止对同一个文件的并行写操作，也是会导致父子线程对同一个文件的交替写。

5.8 Linux 为什么不"帮你复制一个新 file"

这是一个非常有代表性的设计问题。

为什么 dup / fork 不干脆给你一个新的 struct file？

答案依然是那句老话：
语义 + 性能。

shell 的重定向
管道
进程间 I/O 继承

这些机制本来就依赖共享 file 的语义。

如果内核强制拆开 file：

重定向将变得不可实现
管道行为会崩塌
fork/exec 模型被破坏

Linux 选择的是：

给你足够底层、足够真实的语义，
风险由你承担，能力也交给你。

5.9 小结式锚点：fd 复制从来不是"拷贝资源"

把这一章压缩成三句话：

dup / fork 复制的是 引用关系
file 是共享语义的核心
引用计数是这一切成立的物理基础

只要你记住：

"是否共享 struct file" 才是 fd 行为的分水岭

后面关于 close、epoll、I/O 并发的所有现象，

都会变得顺理成章。

底层延伸思考（通往第 6 章）

现在我们已经搞清楚：

fd close ≠ 资源释放
file 的生命周期独立于 fd
引用计数决定一切

那接下来的问题就很自然了：

close(fd) 到底关闭了哪一层？
什么时候资源才真正释放？

下一章，我们会专门把 close() 这一个看似简单的系统调用

拆到 file / inode / 底层设备 三层，

看看它是如何一步步"退场"的。

6. close(fd)：到底关闭了什么

【内核态 · fdtable、file 引用计数、延迟回收、子系统收尾】

close 这个系统调用之所以"看起来简单"，是因为用户态只看到一个 int fd。

但在内核里，这个 int 背后至少串着四层对象和两类生命周期：

fd（进程私有索引）生命周期：一旦从 fdtable 拿掉就结束
file（打开实例）生命周期：由引用计数决定，可能比 fd 长得多
inode/dentry（VFS 持久对象）生命周期：比 file 更长，且不等于"文件存在"
底层资源（socket/pipe/device）生命周期：取决于具体 f_op 的 release/flush/协议状态

如果你把 close 当成"释放文件"，基本等价于把 Linux I/O 模型当成单层结构------后面遇到共享、epoll、fork、竞态就必炸。

6.1 close 的第一刀：从 fdtable 里"拔掉"这个下标

close 的入口（不纠结具体符号名，2.6/5.x 有差异）核心动作是一样的：

sys_close -> ... -> close_fd(fd) -> filp_close(file, ...) -> fput(file)

真正第一步不是 fput，而是：把 fd 从当前进程的 fdtable 里摘掉。

这里发生了一个非常关键但经常被忽略的事实：

fd 作为"进程命名空间里的名字"，在这一刻就已经死亡了。

后面任何行为（引用计数、释放、回调）都不再"认识 fd"。

具体来说，内核会在 current->files 体系里：

校验 fd 是否在范围内、是否被占用
取出 struct file *file = fdt->fd[fd]
清空该槽位：fdt->fd[fd] = NULL
更新 close-on-exec 位图等附属状态（2.6 里非常典型）
释放/降级针对 fdtable 的锁（通常是 spinlock 或 RCU/seq 组合，版本差异很大）

你要抓住一条主线："先断开映射，再处理对象生命周期"。

因为只要还挂在 fdtable 上，别的线程就还能通过这个 fd 找到它。

$!NOTE$
close 的第一步是"从 fdtable 把入口拔掉"，这一步解决的是可达性 ；

真正释放资源解决的是引用计数归零，那是第二阶段的事。

6.2 为什么要先拔 fd 再 fput：这是并发语义，不是代码习惯

很多人看源码时会觉得"反正后面要释放，先 fput 再清槽也行"。

不行。close 的顺序是为了避免最恶心的并发竞态之一：

线程 A：close(fd)
线程 B：read(fd)

如果 A 先把 file 引用计数减到 0 并触发释放，而 fdtable 还没清槽，那么 B 可能在极短窗口里：

通过 fdtable 拿到一个已经进入释放路径的 file 指针
发生 use-after-free（或者在更新内核里，被 RCU/延迟回收挡住，但语义仍然错误）

所以 close 必须先让这个 fd 不可再被解析 ，再做 fput。

这是"名字先死，对象再死"的模型。

6.3 fput：close 的"第二阶段"，也是最关键的分水岭

fput(file) 这一层的语义非常干净：

减少 file 的引用计数
如果没归零：到此结束
如果归零：进入最终释放路径（通常是 __fput）

为什么我说它是分水岭？因为从这一刻开始，"关闭"的含义不再统一------它取决于这个 file 背后的类型：

普通文件：主要是 VFS 收尾（dentry/inode 引用释放）
socket：可能触发协议栈状态机（FIN/RST、队列回收）
pipe/eventfd/signalfd：都是不同的释放语义

也就是说：close 的"效果"不是由 close 决定的，而是由 file->f_op 及其背后子系统决定的。

6.4 file 到底长什么样：哪些字段决定 close 行为

struct file 里和 close 强相关的核心要点至少是这几类:

引用计数语义（file 的生死）

file 作为"打开实例"，生死由引用计数控制。dup/fork/epoll 都可能增加引用，close 只是减少引用。

这解释了"最后一个 close 才真正释放"。
操作表 f_op（决定释放动作）
f_op->release 是"我这个 file 类型在关闭时要做什么"的入口。

普通文件可能很轻，socket 可能很重。
路径关联（dentry/inode 的持有关系）

file 通常持有对 dentry/inode 的引用，释放 file 会顺带减少这些引用。

这解释了"unlink 后仍可读写"：因为 file 持有的是 inode 引用，不是路径名。

$!TIP$
具体来说流程大致是：

持有句柄 ：当你打开文件后，内核会将 inode->i_count（内存引用计数）加 1。

执行 Unlink ：文件名没了，inode->i_nlink（硬链接数）变为 0。但因为你的程序还没关，i_count 依然大于 0。

读写校验 ：当你调用 read(fd, ...) 或 write(fd, ...) 时，内核只检查你的 fd 指向的 struct file 是否合法。只要 struct file 还在，它就能顺着指针找到那个 inode。

硬件映射 ：inode 里面存着磁盘块的地址（Extents/Direct Blocks）。内核才不管有没有文件名，它直接拿着这些地址命令磁盘驱动："把这几个扇区的数据给我读出来！"
而且执行这些步骤的时候也不会调用 iput 去调用驱动删除对应物理存储介质上的数据（如扇区）因为 iput 执行删除前需要判定 i_count 引用和 i_nlink 硬连接数都 > 0;

打开标志与状态（能不能 flush、是否非阻塞等）
一些 flag 会影响关闭时是否需要 flush、是否需要触发某些收尾。

$!NOTE$
fd 只是入口；file 才是"打开行为"的实体。close 的真正语义落点是 file 的引用计数与 f_op 的 release。

6.5 `__fput` 的释放路径：从 VFS 到具体文件系统/设备

当引用计数归零进入最终释放时，内核会做一串"层层退场"的动作。你可以把它理解成把打开行为在 VFS 里的所有钩子逐个拆掉：

调用可能存在的 flush/release 钩子（取决于 file 类型）
释放与路径相关的引用（dentry 相关、mount 相关）
释放 inode 相关引用（可能触发 iput 路径）
释放 file 自身内存（真正 free）

这条路径之所以"深"，是因为 VFS 把职责拆得很干净：

file 不直接代表文件，它代表"打开实例"，所以它的释放动作必须把它持有的各种引用都归还给各自的所有者。

$!Supplement$
你如果写过驱动/文件系统会发现：同一个 close，在不同类型对象上"重量级程度"完全不同。

普通文件 close 很可能只是引用计数清零；socket close 可能触发一整套协议状态机和队列清理。

所以别拿"close 很快"当假设做性能判断，得看 f_op 后面实际文件是谁。

6.6 close 与 "数据是否落盘"：别用 close 承担 fsync 的语义

对普通文件，写入往往先进入 page cache（内存）
close 时，内核可能会做某些同步相关动作（不同 FS、不同时代实现差异大）
但语义上：POSIX 层面并不把 close 定义为"必须持久化成功"

也就是说：

close 解决的是"打开实例的生命周期"，不是"持久化承诺"。

你要持久化语义，必须显式 fsync/fdatasync，或者依赖文件系统的特定语义（别默认）。

把 close 当"提交事务"，是工程上非常常见的误判。

6.7 最阴的坑：close 的 fd 复用与竞态

这里是 close 的"现实世界杀伤力"。

close 把 fdtable 槽位清空后，这个数字 可以立刻被复用。于是出现经典竞态：

线程 A：close(3)
线程 B：open(...) 可能立刻拿到 fd=3
线程 C：还以为 fd=3 是旧的那个对象，继续 read/write

用户态看起来像"旧 fd 复活了"，本质是：fd 只是编号，编号复用是必然的。

$!Question$
为什么多线程程序里"传递 fd"必须极其小心？

因为 fd 是可复用的名字，不是稳定句柄。要传递稳定性，你得传递"拥有权"（例如用同步、引用计数、或传递 file 描述符本身的语义，例如 SCM_RIGHTS）。

这也是为什么很多工程实践会强调：
不要用裸 fd 做跨线程长期身份标识，更不要缓存 fd 假设它永远指向同一个对象。

6.8 close 与 epoll/io_uring：为什么你关了 fd 事件还在

你前面提到"close 后 epoll 还能看到动静"，这里把原因说透：

epoll 之所以可靠，是因为它不靠 fd 这个名字做绑定 ，它在 epoll_ctl 阶段会拿到并持有更底层的东西（本质上围绕 file 建立关系）。因此：

你 close(fd) 只是把"你这边的入口"拔掉
只要事件系统/异步系统仍持有引用，file 就不会立刻消亡
回调、事件触发仍然可能发生（直到引用释放、清理完成）

这也是为什么你在复杂异步 I/O 场景里，close 往往不是"结束"，而是"开始收尾"。

6.9 close() 一句话

如果要一句话把 close 的底层语义说干净，我会这么写：

close(fd) 做两件事：
（1）让 fd 这个名字在当前进程不可达；（2）对 file 做一次 fput，是否真正释放取决于引用计数与 f_op 的收尾逻辑。

底层延伸思考（通往第 7 章）

现在你应该能回答一个更硬的问题了：

close 的核心不是"释放"，而是"撤销可达性 + 触发引用回收"。

那事件系统为什么敢绕开 fd，只盯住 file？

它到底把"可达性"钉在哪里？

下一章我们就把这个钉子拔出来：
epoll 的对象绑定、回调挂载点、以及为什么它能避免 select/poll 的 O(n) 扫描。

7. fd 与 epoll：事件系统为什么必须绕开 fd

【内核态 · epoll 的对象选择与事件传播模型】

在前六章里，我们已经反复强调一件事：
fd 只是进程私有的名字，而不是内核世界里的稳定对象。

epoll 之所以"看起来像 fd 的升级版"，只是因为它在用户态 API 上仍然接收 fd。

但在内核设计层面，epoll 从一开始就不是 fd 级别的机制。

这一章要解决的不是"epoll 怎么用"，而是一个更根本的问题：

如果你站在内核设计者的视角，
为什么 epoll 必须抛弃 fd，直接绑定 struct file？

7.1 先把问题说死：fd 在事件系统里是不合格的锚点

如果我们假设 epoll 是"监听 fd"，那么内核立刻会撞上三个不可解的问题：

fd 是进程私有的
- epoll 实例本身也是一个 fd
- fd 的解释必须依赖 current->files
- 事件源却可能来自别的执行上下文（软中断、网络协议栈）
fd 会被复用
- close(fd) 后，fd 号立刻可以重新分配
- 新 fd 可能指向完全不同的 file
- 事件系统无法区分"旧 fd=3"与"新 fd=3"
fd 本身不具备"可等待语义"
- fd 只是一个整数
- 它没有等待队列
- 它无法主动唤醒任何东西

如果 epoll 真的绑定在 fd 上，那么它要么：

退化成 select/poll 的扫描模型
要么在 fd 复用场景下产生不可修复的歧义

这在内核层面是不可接受的。

7.2 epoll 的第一步：通过 fd 找到真正的锚点

现在我们顺着源码走。

用户态调用：

c 复制代码

epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);

内核路径（2.6 语义，简化）是：

复制代码

sys_epoll_ctl
  -> epoll_ctl
     -> ep_insert

在 ep_insert 的最开始，内核做的第一件事不是"登记 fd"，而是：

**通过 current->files，把 fd 翻译成 struct file ***。

也就是说：

fd 只在 这一刻 有意义
它的作用只是：

👉 "帮我定位你想监听的那个 file"

一旦 struct file * 拿到手，fd 在 epoll 内部逻辑里就彻底消失了。

7.3 epitem：epoll 内部真正的事件实体

epoll 内部并不存在"fd 监听项"，而是存在一种更底层的对象：

epitem

你可以把 epitem 理解为一句话：

"某个 epoll 实例，对某个 struct file 的一次事件订阅"。

一个 epitem 至少绑定三样东西：

一个 epoll 实例（eventpoll）
一个 struct file（事件源）
一组事件掩码（EPOLLIN / EPOLLOUT ...）

源码层面（路径级别）：

c 复制代码

fs/eventpoll.c
  struct epitem {
      struct rb_node rbn;        // 挂在 epoll 实例的红黑树
      struct list_head rdllink;  // 就绪链表
      struct epoll_filefd ffd;   // 包含 struct file *
      ...
  };

注意：
epitem 持有的是 file 指针，而不是 fd。

这一步在设计上非常关键：

epoll 的对象模型，从这一刻起就与"进程 fd 命名空间"彻底解耦。

7.4 epoll 真正监听的不是 file，而是 file 背后的等待队列

到这里还不够。

如果 epoll 只是"盯着 file"，它仍然需要轮询 file 的状态。

那它就和 poll 没本质区别。

epoll 真正高效的原因，在于它做了下一步：

把回调函数，直接挂到 file 所代表对象的等待队列上。

这一步发生在 ep_insert 的后半段：

复制代码

ep_insert
  -> init_poll_funcptr
  -> file->f_op->poll

这里发生了一件极其重要的事情：

epoll 调用 file 的 poll 方法
poll 方法把 epoll 的回调函数
挂到该 file 对应对象的 waitqueue 上

也就是说：

epoll 不是"去问 file 现在能不能读"，
而是告诉 file：
"等你将来有事，记得叫我。"

7.5 事件是如何"主动送到 epoll"的

现在我们把时间轴拉到未来。

假设监听的是一个 socket：

网络数据到达
协议栈把数据放入 socket buffer
socket 状态发生变化
socket 唤醒自己的 waitqueue
waitqueue 上的 epoll 回调被触发
对应 epitem 被放入 epoll 的就绪链表
epoll_wait 直接返回"已经发生的事件"

整个过程中：

没有扫描
没有遍历 fd
没有 O(n)

这也是为什么 epoll 的复杂度不在 wait 阶段，而是在 注册阶段。

$!NOTE$
epoll 的本质不是"高效轮询"，

而是 事件源主动通知。

7.6 为什么 close(fd) 之后，epoll 仍然"活着"

现在我们可以严丝合缝地解释那个经典现象了。

当用户态调用：

c 复制代码

close(fd);

内核发生的是：

fd 从 fdtable 移除
对 struct file 执行一次 fput

但注意：
epitem 仍然持有 struct file 的引用。

因此：

file 不会被释放
file 对应的 waitqueue 仍然存在
epoll 的回调仍然挂在上面

所以：

close(fd) 只会让"你这个进程"不再能通过 fd 访问 file，
并不会立即终止 epoll 对该 file 的监听关系。

这不是"epoll 的怪异行为"，而是 file 引用计数语义的必然结果。

7.7 epoll 为什么天然规避 fd 复用问题

现在回到一个工程级灾难问题：

fd 被 close 后立即复用，epoll 会不会搞混？

答案是：不会，也不可能。

因为：

epoll 内部从来不存 fd
它存的是 struct file 指针
新 open 得到的 fd=3，必然对应新的 file
新 file 与旧 file 在内核中是两个不同对象

这就是 epoll 绕开 fd 的最直接收益：

fd 可以随意复用，但事件系统的锚点永远稳定。

7.8 select / poll 与 epoll 的根本分水岭

现在你再回头看 select / poll 的局限，就会非常清楚：

select / poll
- 只能站在 fd 层
- 每次都要扫描
- 内核无法"记住未来的事件"
epoll
- 直接站在 file / waitqueue 层
- 事件发生时主动通知
- wait 阶段几乎不做无用功

这不是"实现技巧差异"，而是：

对象选择层级的差异。

7.9 本章落点

如果你要用一句话，把 epoll 的内核模型说清楚，那只能是这句：

epoll 不是 fd 的集合，
而是一组"对 struct file 的事件订阅关系"。

fd 只是入口参数；

file 才是事件源；

waitqueue 才是唤醒机制。

8. fd 的边界：上限、泄漏与系统级后果

【内核态 · 资源配额、对象生命周期、系统稳定性】

如果说前七章讲的是 fd 的"语义世界"，

那这一章讲的就是 fd 的物理世界。

因为无论抽象设计多优雅，fd 最终都会撞上三个无法回避的问题：

fd 到底能开多少？
fd 泄漏为什么能拖垮整个系统？
"Too many open files" 究竟卡在了哪一层？

这三个问题，没有一个是用户态能单独回答的。

8.1 先给一个总览：fd 的限制不是一层，而是三层叠加

这是整章必须先钉死的结论：

fd 的上限从来不是一个数，而是三套限制的叠加结果。

这三层分别是：

进程级限制（per-process）
系统级限制（system-wide）
内核对象与内存限制（object & memory）

只要你漏看任何一层，

排查 fd 问题时就一定会得出错误结论。

8.2 第一层：进程级 fd 上限（RLIMIT_NOFILE）

最外层、也是用户最熟悉的一层，是：

bash 复制代码

ulimit -n

但在内核视角里，这个东西叫：

RLIMIT_NOFILE

它的真实含义不是"你最多能 open 多少文件"，

而是：

"一个进程最多能在 fdtable 里拥有多少个活跃 fd 槽位"

这层限制，直接作用在：

current->files->fdtable
get_unused_fd_flags() 分配 fd 的那一步

也就是说：

fdtable 还没扩容到这个值，内核就会拒绝你。

这一步失败，通常直接返回：

复制代码

EMFILE  (Too many open files)

注意一个非常容易被忽略的点：

RLIMIT_NOFILE 限的是 fd 数量 ，

而不是 file 对象数量。

dup / fork / epoll 可能让 file 数量远小于 fd 数量，

也可能相反。

8.3 第二层：系统级 file 对象上限（fs.file-max）

现在假设你把 ulimit -n 调得很大，

进程级限制不再是瓶颈。

问题来了：
内核是不是就能无限创建 struct file？

答案显然是否定的。

Linux 有一个明确的 系统级 file 对象上限，通常暴露为：

bash 复制代码

/proc/sys/fs/file-max

这个限制约束的是：

整个系统中，同时存在的 struct file 对象总数。

这层限制卡的不是 fdtable，而是 file 的分配路径。

当系统里所有进程的打开实例加起来，

struct file 数量逼近上限时：

即便某个进程的 RLIMIT_NOFILE 还有空间
即便 fdtable 还能扩容
open() 仍然会失败

并且返回的错误往往是：

复制代码

ENFILE  (Too many open files in system)

这一步的失败位置，已经不在进程私有路径上了 ，

而是在系统级资源分配阶段。

8.4 为什么系统级 file 上限一定存在

这是一个"设计者视角"的问题。

struct file 并不是一个轻量对象，它至少隐含着：

引用计数
指向 inode / dentry 的关系
f_op 表
等待队列/异步 I/O 关联
cache 与锁相关结构

也就是说：

每一个 file，都是一个可参与调度、等待、唤醒的内核对象。

如果 file 数量无限制：

内核内存会被迅速吃光
waitqueue / epoll / AIO 复杂度会失控
系统整体稳定性无法保证

所以 fs.file-max 的本质不是"限制用户"，

而是：

限制内核对象规模，保证系统可预测性。

8.5 第三层：真正的杀手------内核内存与对象链条

现在来到最容易被忽视、但杀伤力最大的那一层。

fd 泄漏真正可怕的地方，并不在 fd 本身 ，

而在于它会拖住一整条对象链。

我们把这条链明确写出来：

复制代码

fd
 → struct file
   → struct dentry
     → struct inode
       → page cache
         → 内核内存

只要 fd 没被 close：

file 的引用计数不会归零
inode 无法回收
page cache 无法释放
内核内存长期被占用

所以你在实际系统中看到的往往是：

fd 数量缓慢增长
file-max 逐渐逼近
内存压力异常
最终触发 OOM 或系统不稳定

而不是"突然 fd 用完"。

$!NOTE$
fd 泄漏是一种慢性系统资源泄漏 ，

它的症状往往出现在内存、I/O 延迟、调度抖动上，而不是第一时间报错。

8.6 为什么 fd 泄漏比 malloc 泄漏更危险

这是一个非常"工程现实"的对比。

malloc 泄漏
- 只影响当前进程
- 进程退出即可回收
fd 泄漏
- 影响系统级 file 对象池
- 影响 VFS、网络、块设备
- 可能拖垮整个系统

尤其在服务端程序中：

一个长期运行的进程
每秒泄漏几个 fd
几小时后，整个系统开始异常

这也是为什么 fd 泄漏经常表现为"系统问题"而不是"程序问题"。

8.7 ulimit 调大了，为什么还是 "Too many open files"

这是面试和线上都极其常见的"认知陷阱"。

原因通常只有三类：

撞的是系统级 file-max，而不是进程级 RLIMIT
file 对象被 epoll / 其他子系统持有，迟迟不释放
fd 泄漏导致 file 引用长期不归零

如果你只盯着 ulimit -n，

而不看：

/proc/sys/fs/file-nr
当前系统 file 使用量
是否存在 file 引用悬挂

那你看到的只会是"现象"，而不是"原因"。

8.8 fd 上限的本质：限制的是"可达性"，不是"能力"

回到 fd 的抽象本质，你会发现一件很有意思的事：

fd 的上限，本质上是在限制"一个进程能同时持有多少个内核对象入口"。

它并不限制你"能不能做 I/O"，

而是限制你：

同时打开多少对象
同时维持多少资源关系
同时参与多少等待/唤醒链路

这也是为什么 Linux 宁愿：

把限制做成多层
把错误早早返回
也不愿让系统进入不可控状态

底层延伸思考（为全文收尾埋点）

现在，整条 fd 主线已经完整闭环：

用户态看到的是 int
内核里是 files_struct → file → inode
事件系统绕过 fd，直连 file
资源限制卡在对象与内存层

最后一个问题，其实已经呼之欲出：

Linux 为什么要设计 fd 这一层，而不是直接把 file 暴露给用户态？
$!Important$
这个问题，不是技术细节，而是 操作系统设计哲学。

首先操作系统不可能把内核地址直接给你，只能是给你一个对于操作系统可控的操作方式，就像你是去银行取号一样，而不是直接去银行的金库拿钱。操作系统在用户层只能给你一个句柄（排队取号），然后统一通过系统提供的一切皆文件抽象统一控制底层的普通文件、epollfd、timefd、socket、pipe等等内核结构体。

抽象是降低项目复杂度的十分好用的方式，Linux将内核"文件"抽象使用到极致也就是我们常说的"一切皆文件"的设计哲学，他们用统一的用户层皮囊 fd 找到内核层的 current->file->fdt[fd] 这个 struct file 然后通过统一的 file 结构体的 f_ops 指针数组指向 read\write\close\open 等等一系列操作，然后这是统一接口（函数指针），其具体指向了更底层的具体的实现也就是 OOP的多态

THE END

如果回到最根本的问题：
Linux 为什么要设计 fd，而不是把内核对象直接暴露给用户态？

这个问题，本质上就不是某个系统调用的实现细节，而是操作系统的设计哲学。

fd 是一种"受控访问权"，而不是资源本体

操作系统不可能、也绝不会把内核地址空间直接交给用户态。

无论是 struct file、inode，还是等待队列和回调链路，它们都必须完全由内核掌控。

fd 的角色，恰恰是一种可控的操作凭证。

更贴切的比喻不是"指针"，而是银行取号 ：

你拿到的不是金库钥匙，而只是一个编号；

真正的资源始终锁在内核里，

你只能通过这个编号，按照操作系统规定的流程去"办理业务"。

也正因为如此，Linux 才能在用户态只暴露一个整数 fd，

却在内核里统一调度普通文件、socket、pipe、epollfd、timerfd 等完全不同的对象。

"一切皆文件"，本质是对复杂度的极端压缩

Linux 把"文件"这一抽象推到了极致。

在用户态，看起来只有：

复制代码

fd → read / write / close

但在内核里，这条路径迅速展开为：

复制代码

fd
 → current->files->fdtable[fd]
   → struct file
     → file->f_op
       → 具体子系统实现

fd 只是统一的"皮囊"，

真正的能力集中在 struct file，

而多态则通过 f_op 这一组函数指针完成。

这并不是巧合，而是一个极其工程化的选择：
用统一的接口，把完全不同的底层实现收敛到同一条调用路径上。

从这个角度看，VFS 并不是"文件系统层"，

而是 Linux 在内核里实现的一套面向对象的运行时多态机制。

fd 设计本质是高内聚低耦合

fd 的设计几乎几十年未变，但内核内部却早已天翻地覆：

file 结构体不断演进
epoll、aio、io_uring 不断出现
等待队列、回调机制、引用计数模型持续重构

这一切都没有破坏 fd 这个接口。

原因只有一个：

fd 把用户态与内核态之间的边界压缩到了最窄。

边界越窄，内核就越自由；

接口越简单，系统就越稳定。

写在最后

当你真正理解 fd 之后，会发现它并不是 Linux I/O 世界里最复杂的部分，

但它恰恰是最关键的那一道门。

fd 不保存状态、不承载语义、也不代表资源本体，

它只是一个受控入口。

而 Linux 所有复杂而优雅的设计，

都发生在 fd 背后那片你永远触碰不到的内核世界里。

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

文章目录

0. fd 不是文件，这是理解 Linux I/O 的第一道门

1. 用户态眼中的 fd：一个被严重低估的 int

1.1 fd 在 API 里的角色定位

1.2 fd 与"文件"的常见误解

1.3 为什么 fd 必须是 int，而不是指针或句柄对象

1.4 用户态这一层，Linux 刻意让你"看不见"

2. fd 在内核中的真正归属：task_struct → files_struct

2.1 从 current 出发：fd 不属于系统，只属于进程

2.2 task_struct 里的 files：为什么 fd 管理权在这里

2.3 files_struct：进程的 fd 命名空间

2.4 fdtable：fd → struct file 的真正映射层

2.5 为什么 fd 是 per-process，而不是 per-thread

2.6 小结式锚点：fd 在内核的第一落点

3. fd 指向的核心对象：struct file 的职责边界

3.1 一个容易被误解的事实：file 不是"文件"

3.2 file 为什么必须存在：VFS 的"最小统一抽象"

3.3 f_pos：为什么文件偏移放在 file，而不是 inode

3.4 f_op：fd 能"读一切"的真正原因

3.5 file 的生命周期：fd close 并不等于 file 消亡

3.6 file、inode、dentry：三者的职责边界

底层延伸思考（通往第 4 章）

4. open() 全链路：fd 是在哪一步诞生的

4.1 从用户态 open() 开始：真正重要的不是路径字符串

4.2 syscall 入口：open 并不直接干活

4.3 do_filp_open：file 的诞生点

4.4 file 在这里是"打开行为的证明"

4.5 fd 的分配：get_unused_fd 的真实角色

4.6 fd_install：fd 与 file 的正式绑定

4.7 为什么 fd 一定在最后才分配

4.8 一条完整的调用链，背后的设计取舍

底层延伸思考（通往第 5 章）

5. dup / fork：fd 复制的真正含义

5.1 一个必须先打掉的误区：dup ≠ 打开新文件

5.2 dup 在内核里到底复制了什么

5.3 fork：比 dup 更"危险"的共享

5.4 为什么 fork 不立刻复制 fdtable

5.5 fork 之后，父子进程如何"各自修改 fd"

5.6 file 的引用计数：共享语义的真正支点

5.7 一个极其重要的并发语义：共享 f_pos

5.8 Linux 为什么不"帮你复制一个新 file"

5.9 小结式锚点：fd 复制从来不是"拷贝资源"

底层延伸思考（通往第 6 章）

6. close(fd)：到底关闭了什么

6.1 close 的第一刀：从 fdtable 里"拔掉"这个下标

6.2 为什么要先拔 fd 再 fput：这是并发语义，不是代码习惯

6.3 fput：close 的"第二阶段"，也是最关键的分水岭

6.4 file 到底长什么样：哪些字段决定 close 行为

6.5 __fput 的释放路径：从 VFS 到具体文件系统/设备

6.6 close 与 "数据是否落盘"：别用 close 承担 fsync 的语义

6.7 最阴的坑：close 的 fd 复用与竞态

6.8 close 与 epoll/io_uring：为什么你关了 fd 事件还在

6.9 close() 一句话

底层延伸思考（通往第 7 章）

7. fd 与 epoll：事件系统为什么必须绕开 fd

7.1 先把问题说死：fd 在事件系统里是不合格的锚点

7.2 epoll 的第一步：通过 fd 找到真正的锚点

7.3 epitem：epoll 内部真正的事件实体

7.4 epoll 真正监听的不是 file，而是 file 背后的等待队列

7.5 事件是如何"主动送到 epoll"的

7.6 为什么 close(fd) 之后，epoll 仍然"活着"

7.7 epoll 为什么天然规避 fd 复用问题

7.8 select / poll 与 epoll 的根本分水岭

7.9 本章落点

8. fd 的边界：上限、泄漏与系统级后果

8.1 先给一个总览：fd 的限制不是一层，而是三层叠加

8.2 第一层：进程级 fd 上限（RLIMIT_NOFILE）

8.3 第二层：系统级 file 对象上限（fs.file-max）

8.4 为什么系统级 file 上限一定存在

8.5 第三层：真正的杀手------内核内存与对象链条

8.6 为什么 fd 泄漏比 malloc 泄漏更危险

8.7 ulimit 调大了，为什么还是 "Too many open files"

8.8 fd 上限的本质：限制的是"可达性"，不是"能力"

底层延伸思考（为全文收尾埋点）

THE END

fd 是一种"受控访问权"，而不是资源本体

"一切皆文件"，本质是对复杂度的极端压缩

fd 设计本质是高内聚低耦合

写在最后

6.5 `__fput` 的释放路径：从 VFS 到具体文件系统/设备