在 Linux 和 Android（基于 Linux 内核）中，文件描述符 (File Descriptor, 简称 Fd) 是一个非负整数。它是操作系统内核为了高效管理已打开的文件或其他资源（如网络套接字、管道）而分配给进程的一个“索引ID”。

以下是从 Linux 基础到 Android 特性的深入理解：

核心概念：什么是 Fd？

在 Linux 的哲学中，“一切皆文件”。这意味着不仅普通的文本文件是文件，目录、键盘、显示器、网络连接、甚至内存片段在内核看来都是“文件”。

当你打开或创建一个文件时，内核会做两件事：

1. 在内核空间创建一个 file 结构体，代表这个被打开的文件。
2. 向进程返回一个整数（即 Fd），这个整数是该进程文件描述符表（Fd Table）的索引。

Fd,File Descriptor Table,系统文件表 (Open File Table / struct file),Inode 与 Dentry (VFS 层)关系

• Fd是一个非负整数，存在于用户空间，作为进程访问内核资源的"号码牌"，仅在当前进程内部有效。
• File Descriptor Table : 文件描述符表是内核空间中进程私有的数组结构（位于 task_struct -> files_struct），数组下标即为 Fd，数组内容是指向系统文件表（struct file）的指针，用于建立 Fd 到内核文件对象的映射关系。
• 系统文件表(struct file)位于内核空间，代表一个"打开的文件会话"，记录当前文件偏移量、访问模式（只读/只写/追加）和引用计数，用于隔离不同进程或同一进程多次打开同一文件时的操作状态。
• Dentry(目录项): 代表文件的路径和文件名，Linux 通过 Dentry 缓存（dcache）提高路径查找速度，指向 Inode
• Inode 代表磁盘上的物理文件，存储文件大小、权限、创建时间和数据块位置等元数据，但不包含文件名（文件名存储在 Dentry 中），且每个文件在内存中只有唯一一个 Inode 实例。

可以把这四层结构想象成一个“从用户态到硬件态”的层级连接：

进程 (Process) 持有 FD↓ (索引)文件描述符表 (FD Table)↓ (指针)系统文件表 (struct file) —— 关键点：记录偏移量↓ (指针)Dentry (目录项) —— 关键点：文件名与路径↓ (指针)Inode (索引节点) —— 关键点：真正的文件实体

比如: 

App (拥有 Fd=3) --> 查表 fd_array[3] --> 找到 struct file --> 找到 inode --> 读写磁盘/设备

场景一：同一个进程，多次打开同一个文件

根据前面的描述,当同一个进程多次打开同一个文件时,会发生以下情况:

文件描述符表 (FD Table)

• 进程会获得多个不同的 Fd(比如 fd3、fd4),每个 Fd 在进程的文件描述符表中是不同的索引

系统文件表 (struct file)

• 内核会为每次 open 操作创建独立的 struct file 对象
• 这意味着每个 Fd 指向不同的 struct file,它们有各自独立的文件偏移量(offset)和访问模式

Inode 层

• 虽然有多个 struct file,但它们最终指向同一个 Inode,因为物理文件是同一个

实际影响

• 进程通过 fd3 读取文件到 100 字节位置,不会影响 fd4 的偏移量
• 两个 Fd 可以同时操作同一文件的不同位置,互不干扰

场景二：父子进程 fork() 或 dup() 复制

fork() 复制

当父进程调用 fork() 创建子进程时:

• 子进程会继承父进程的文件描述符表,获得相同的 Fd 数值（比如父进程的 fd3,子进程也有 fd3）
• 关键点:父子进程的这些 Fd 指向同一个 struct file 对象
• 这意味着父子进程共享文件偏移量——如果父进程读取了文件到 100 字节位置,子进程继续读取时会从 101 字节开始
• 它们也共享同一个 Inode,因为指向的是同一个物理文件

dup() 复制

当调用 dup() 或 dup2() 复制文件描述符时:

• 会在当前进程的文件描述符表中创建一个新的 Fd（比如原来是 fd3,复制后得到 fd4）
• 新旧两个 Fd 指向同一个 struct file 对象
• 效果与 fork() 类似:两个 Fd 共享文件偏移量和访问模式

与场景一的区别

这与场景一（同一进程多次 open 同一文件）不同:

• 场景一:每次 open 都创建独立的 struct file,各有独立的偏移量
• 场景二:fork()/dup() 后共享同一个 struct file,偏移量会相互影响

场景三：硬链接 (Hard Link)

Dentry 层

• 硬链接会创建多个不同的 Dentry(目录项),每个 Dentry 代表不同的文件名和路径
• 这些不同的 Dentry 都指向同一个 Inode

Inode 层

• 虽然有多个文件名(多个 Dentry),但它们共享同一个物理文件实体
• 文件的元数据(大小、权限、数据块位置等)只存储一份

实际效果

• 修改任何一个硬链接文件的内容,其他硬链接文件也会同步变化,因为它们本质上是同一个物理文件
• 删除其中一个硬链接,只是删除了一个 Dentry,不会影响实际的文件数据,只有当所有硬链接都被删除后,Inode 和文件数据才会被真正释放

与前面场景的区别

• 场景一(多次打开):每个 Fd 有独立的 struct file 和偏移量
• 场景二(fork/dup):多个 Fd 共享同一个 struct file
• 场景三(硬链接):多个文件名(Dentry)共享同一个 Inode

默认的 Fd

每个 Linux 进程启动时，默认都会打开三个 Fd：

• 0: 标准输入 (stdin)
• 1: 标准输出 (stdout)
• 2: 标准错误 (stderr)

后续打开的文件通常会从 3 开始分配。

创建FD的方式及其类型

基础文件与目录 (File System)

这是最传统的 Fd 来源，指向文件系统中的节点。

设备 I/O (Devices)

Linux 中设备也是文件，通常位于 /dev/ 下。

网络与 IPC (Sockets & Pipes)

用于进程间通信或网络通信。

内存与共享内存 (Memory)

现代 Linux 和 Android 高度依赖此类 Fd 进行大块数据传输。

从内核源码 (struct file_operations) 的角度看，虽然创建 API 有几十种，但归根结底主要分为三类：

1. 真实文件系统 (VFS based): 指向 Ext4, F2FS, ProcFS 等挂载点上的 inode。
• Examples: open, openat
2. 匿名节点 (Anonymous Inodes): 没有挂载到文件系统树上，只存在于内核内存中，专门为了提供 FD 句柄。
• Examples: epoll, eventfd, bpf, perf_event (显示为 anon_inode:[type])
3. 网络协议栈 (Networking): 指向 Socket 结构体。
• Examples: socket, accept (显示为 socket:[inode])

内核限制和数据结构限制

数据结构限制：select 的 1024 陷阱

这是最著名的 API 结构限制。古老的 select 系统调用使用固定大小的位图 (fd_set)，导致其默认只能监听 1024 以内的 Fd。如果 Fd 数值超过 1024，会导致内存越界。

进程级阈值：Soft & Hard Limit

这是开发中最常遇到的限制，由内核配置决定。

• Soft Limit (软限制)：进程当前的实际上限。达到此值时，open 调用失败并报 EMFILE（Too many open files）。默认通常为 1024。
• Hard Limit (硬限制)：软限制能调整到的最大值。非 Root 用户无法突破此线。
• 调整：可通过 ulimit -n 或 setrlimit 修改。

系统级与物理资源限制

• 全局上限 (fs.file-max)：操作系统允许所有进程打开文件总数的硬性天花板，防止内核内存耗尽。
• 内存消耗 (OOM)：Fd 表本质是数组，打开的文件本质是内核对象 (struct file)。即使阈值设为无限，每一个 Fd 都要占用不可交换的内核内存（Kernel Slab）。海量 Fd 最终会导致系统 OOM（内存溢出）。

select的fd递增特性

指 Fd 的数值 (Index) 超过 1024。select 底层使用固定长度的位图 (Bitmap)，它是直接利用 Fd 的数值作为数组下标进行标记的（类似于 array[fd] = 1）。因此，哪怕你当前只打开了 1 个文件，只要这个文件的 Fd 编号是 1025，就会导致内存越界访问，进而引发程序崩溃。

疑问

select创建的fd的索引,在不同线程,会从0开始计吗

不会,同一个进程的不同线程共享同一个文件描述符表（fd table），因此：在同一个进程内，所有线程看到的 fd 编号是全局唯一的

哪些创建 fd 的方式会导致 file descriptor 1050 >= FD_SETSIZE 1024 这个错误？

这个错误（FORTIFY: FD_SET / FD_ISSET / FD_CLR: file descriptor xxx >= FD_SETSIZE 1024）本质上不是 fd 创建本身引起的，而是后续代码使用了 select()（或 pselect()） + fd_set 来监控这些 fd 时触发的。

只要创建的 fd 值 ≥ 1024，且后续在同一个进程中用 select() 监控它（调用 FD_SET(fd, &set)、FD_ISSET() 等），就会因为 fd_set 的位图大小固定为 1024 而越界，导致 Android 的 fortified libc 直接 abort()。

select, poll, epoll在同一个进程是同用一份fd 数值吗?

是的，完全共用同一份数值。

Fd 的数值（例如 3, 5, 1050）是由操作系统内核在资源创建（如 open, socket）时统一分配的，属于进程全局的资源。

select、poll、epoll 只是三种不同的监控工具，它们操作的对象完全相同：

• 如果你打开一个 Socket 得到了 Fd 888。
• 给 select 用，你传入 888。
• 给 poll 用，你传入 888。
• 给 epoll 用，你还是传入 888。

唯一的区别在于兼容性：如果内核给你分配了一个很大的数值（比如 2000），poll 和 epoll 能正常工作，但 select 会因为这个数值太大而崩溃。