Linux中打开文件表的实现机制：动态扩容还是静态数组？

Linux 内核里，进程的文件句柄（也就是文件描述符）存储采用了静态数组+动态扩容的混合方案，完美平衡了性能和空间利用率，具体逻辑如下：

• 核心管理结构：files_struct
  每个进程都有一个files_struct结构体，专门负责管理自己的文件描述符表——这张表就是用来记录进程打开的所有文件的映射关系的。

• 初始静态数组：fd_array
  内核默认给每个进程分配了一个固定大小的静态数组fd_array（默认容量通常是64，由宏NR_OPEN_DEFAULT定义）。绝大多数进程平时打开的文件数量都不会超过这个数，直接用静态数组可以跳过动态内存分配的开销，性能拉满。

• 动态扩容逻辑
  当进程打开的文件数量超过fd_array的上限时，内核会自动切换到动态分配的fd_table数组。这个动态数组是按内存页为单位扩容的——比如x86架构下一页是4KB，能存1024个文件描述符指针，每次扩容就加一整页。这种方式既保证了内存的连续性，又能减少碎片，完全适配内核的内存管理机制，比C++ vector的固定倍数扩容更贴合操作系统的需求。

• 自动收缩机制
  当进程关闭大量文件，文件描述符数量降到动态数组容量的一半以下时，内核会自动释放多余的内存页；如果数量回到fd_array的容量以内，还会切回静态数组存储，彻底避免闲置内存的浪费。

• 为什么不选单一方案？

  • 如果只用超大静态数组：每个进程都会占用大量闲置内存，系统里成百上千个进程加起来，内存浪费会非常夸张，服务器场景根本扛不住。
  • 如果完全用动态扩容：小数量场景下会频繁触发内存分配/释放，额外开销会拖慢进程性能，而绝大多数进程的文件句柄数量都很小，这完全没必要。

内容的提问来源于stack exchange，提问作者Meharjeet Singh