文件描述符/文件句柄/文件指针的区别与联系

目录

​​进程级别的文件描述符 & 文件描述符表​​

​​文件描述符​​

​​文件描述符表​​

​​系统级别的打开文件表 & 文件句柄​​

​​打开文件表​​

​​文件句柄​​

​​举例​​

​​文件系统 的索引节点 inode（index node）表​​

​​inode定义​​

​​查看 inode 相关信息​​

​​查看文件的 inode 号​​

​​inode 大小​​

​​inode 数量​​

​​增删改文件对于inode的影响​​

​​复制​​

​​移动​​

​​硬链接（hard link）​​

​​软链接（soft link）​​

​​删除​​

​​文件I/O API & 文件指针​​

​​文件I/O API​​

​​文件指针​​

​​其他问题​​

​​系统级别的文件句柄数量限制​​

​​进程级别（用户级别）的文件描述符的限制​​

​​文件描述符造成的串话问题​​

​​串话问题​​

​​解决方法​​

​​重定向标准输出fd，标准错误输出fd的问题​​

​​总结​​

---

 每一个文件描述符会与一个打开文件相对应；

不同的文件描述符也会指向同一个文件。

相同的文件可以被不同的进程打开也可以在同一个进程中被多次打开。

系统为每一个进程维护了一个文件描述符表，该表的值都是从0开始的，所以在不同的进程中你会看到相同的文件描述符，这种情况下相同文件描述符有可能指向同一个文件，也有可能指向不同的文件。具体情况要具体分析，要理解具体其概况如何，需要查看由内核维护的3个数据结构。
    1. 进程级的文件描述符表
    2. 系统级的打开文件描述符表
    3. 文件系统的i-node表

文件描述符表、打开文件表、inode表之间的关系可以用书中的下图来表示。注意图中的fd 0、1、2...只是示意下标，不代表三个标准描述符。

可见，一个打开的文件可以对应多个文件描述符（不管是同进程还是不同进程），一个inode也可以对应多个打开的文件。

文件描述符、文件句柄、文件指针这三个概念很容易混淆，网上其他博客也是众说纷纭。于是做了一点考证，专门写一篇来尽量准确地记录下。

进程级别的文件描述符 & 文件描述符表

文件描述符

文件描述符（file descriptor, fd）是Linux系统中对已打开文件的一个抽象标记，所有I/O系统调用对已打开文件的操作都要用到它。这里的“文件”仍然是广义的，即除了普通文件和目录外，还包括管道、FIFO（命名管道）、Socket、终端、设备等。

文件描述符是一个较小的非负整数，并且0、1、2三个描述符总是默认分配给标准输入、标准输出和标准错误。这就是常用的nohup ./my_script > my_script.log 2>&1 &命令里2和1的由来。

文件描述符表

Linux系统中的每个进程会在其进程控制块（PCB）内维护属于自己的文件描述符表（file descriptor table）。表中每个条目包含两个域：一是控制该描述符的标记域（flags），二是指向系统级别的打开文件表中对应条目的指针。那么打开文件表又是什么呢？

系统级别的打开文件表 & 文件句柄

打开文件表

内核会维护系统内所有打开的文件及其相关的元信息，该结构称为打开文件表（open file table）。

表中每个条目（文件句柄）包含以下域：

文件的偏移量。（POSIX API中的read()/write()/lseek()函数都会修改该值）
打开文件时的状态和权限标记（通过open()函数的参数传入）
文件的访问模式（只读、只写、读+写等）。通过open()函数的参数传入；
指向其对应的inode对象的指针。内核也会维护系统级别的inode表，关于inode的细节请参考 如下；

文件类型（例如：常规文件、套接字或FIFO）和访问权限

文件的各种属性，包括文件大小以及与不同类型操作相关的时间戳；

 

文件句柄

打开文件表中的一行称为一条文件描述（file description），也经常称为文件句柄（file handle）。

“句柄”这个词在UNIX世界中并不很正式，但在Windows里遍地都是。Windows NT内核会将内存中的所有对象（文件、窗口、菜单、图标等一切东西）的地址列表维护成整数索引，这个整数就叫做句柄，逻辑上讲类似于“指针的指针”，感觉上还是有一些相通的地方的。

举例

下图展示了文件描述符、打开的文件句柄以及i-node之间的关系，图中，两个进程拥有诸多打开的文件描述符。

 

在进程A中，文件描述符1和30都指向了同一个打开的文件句柄（标号23）。这可能是通过调用dup()、dup2()、fcntl()或者对同一个文件多次调用了open()函数而形成的。

进程A的文件描述符2和进程B的文件描述符2都指向了同一个打开的文件句柄（标号73）。这种情形可能是在调用fork()后出现的（即，进程A、B是父子进程关系），或者当某进程通过UNIX域套接字将一个打开的文件描述符传递给另一个进程时，也会发生。再者是不同的进程独自去调用open函数打开了同一个文件，此时进程内部的描述符正好分配到与其他进程打开该文件的描述符一样。

此外，进程A的描述符0和进程B的描述符3分别指向不同的打开文件句柄，但这些句柄均指向i-node表的相同条目（1976），换言之，指向同一个文件。发生这种情况是因为每个进程各自对同一个文件发起了open()调用。同一个进程两次打开同一个文件，也会发生类似情况。

 

文件系统 的索引节点 inode（index node）表

inode定义

inode（即index node，索引节点）是类Unix OS中保存文件系统中的对象元数据的数据结构。
具体来讲，inode中主要存储以下这些元数据：

• inode编号
• 文件大小
• 占用的块数目与块大小
• 文件类型（普通文件、目录、管道，etc.）
• 存储该文件的设备号
• 链接数目
• 读、写、执行权限
• 拥有者的用户ID和组ID
• 文件的最近访问、数据最近修改时间
• inode最近修改时间

inode编号相当于这个结构中的“主键”，也就是说操作系统用inode编号唯一标识一个文件。

查看 inode 相关信息

查看文件的 inode 号

利用stat命令可以查看元数据信息，如下图所示。通过ls -i也可以仅查看一个或一批文件的inode编号。

inode 大小

inode存储的元数据也是要占用文件系统空间的，每个inode的大小一般是128B或者256B，这可以通过查询superblock信息的dumpe2fs命令查到。

Linux在格式化硬盘分区（即初始化文件系统）时，就会将inode的区域（称为inode table）与文件数据的区域分开，一般每1KB或2KB数据分配一个inode编号。也就是说，每个分区的inode总数从格式化之后就固定了，因此有可能会出现存储空间没有占满，但因为小文件太多而耗尽了inode的情况。

inode 数量

利用df -i命令可以查看inode数量方面的信息，如下图所示。

增删改文件对于inode的影响

下面我们来看看Linux系统中最常见的几种文件操作是如何体现inode的。

复制

当复制一个文件时，会创建一个包含新inode的新文件。

移动

当移动一个文件时，仅仅是inode指向的位置发生变化，inode编号与实际数据存储的块的位置都不会变化。

硬链接（hard link）

Linux系统允许同一个inode号代表的文件有多个文件名，即可以用不同的文件名访问同一份数据，这叫做硬链接。对一个文件创建硬链接，其inode编号都相同，并且链接数会增加。

如上，一个文件创建了3个硬连接，inode相同，连接数（相当于是inode 的引用计数）为3；

特别地，目录中默认包含的两个项​​.​​​和​​..​​实际上就是对当前目录和父目录的硬链接，inode编号也对应。

但是Linux系统不允许用户对目录创建硬链接，因为Linux的目录结构是无环图，随意创建硬链接之后会产生环。

软链接（soft link）

软链接的本质也是一个文件，其存储的内容是对另一个文件的指针。所以对一个文件创建软链接，inode编号会不同，被指向文件的链接数不会增加。并且可以对目录与不存在的文件创建软链接。

删除

当删除文件时，会先检查inode中的链接数。

如果链接数大于1，就只会删掉一个硬链接，不影响数据。

如果链接数等于1，那么这个inode就会被释放掉，对应的块也会被标记为空闲的。

由上图可以看出，如果把上述profile_copy文件删掉，那么原先创建的两个hardlink文件就变为了两个不同的文件（其中一个文件会继承原来的inode编号），其链接数为1，并且仍然可以正常访问。相对地，softlink文件就变成了悬挂链接（dangling link），不能正常访问了。

利用inode还可以删除一些文件名中有转义字符或控制字符的文件；

最典型的就是开头为减号​​-​​的文件。这种无法直接用rm命令来搞，就可以先查出它们的inode编号再删除：

find ./ -inum 10086 -exec rm {} \:

文件I/O API & 文件指针

文件I/O API

说了这么多，用最基础的POSIX库函数写个示例程序吧。它将一个文件中的内容读出来，并原封不动地写入另外一个文件。

#include <fcntl.h>
#include <sys/stat.h>
#define BUF_SIZE 1024

int main(int argc,char *argv[]) {
  int inputFd, outputFd;
  char buf[BUF_SIZE];
  ssize_t numRead;

  inputFd = open("data.txt", O_RDONLY);
  if (inputFd == -1) {
    exit(EXIT_FAILURE);
  }
  outputFd = open(
    "data_copy.txt", 
    O_CREAT | O_WRONLY | O_TRUNC,
    S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH
  );
  if (outputFd == -1) {
    exit(EXIT_FAILURE);
  }

  while ((numRead = read(inputFd, buf, BUF_SIZE)) > 0) {
    if (write(outputFd, buf, numRead) != numRead) {
      exit(EXIT_FAILURE);
    }
  }
  
  close(inputFd);
  close(outputFd);
  exit(EXIT_SUCCESS);
}

严格来讲，POSIX提供的这些函数只是用户与内核之前的桥梁，实际仍位于系统调用层之上。但是现实应用中，我们一般也把它们叫做系统调用了（尽管不太正确）。

要使用open()/read()/write()/close()这些系统调用，必须引入fcntl.h头文件。

open()返回的是文件描述符，其参数中传入的flags和mode值也会保存在打开文件表中。在整个读、写并最终关闭文件的过程中，操作的也都是文件描述符。

文件指针

那么我们在大学C语言课程上学习的“文件指针”（file pointer）又是什么呢？这个就比较简单，继续看下面的栗子。

#include <stdio.h>
#include <stdlib.h>
#define BUF_SIZE 1024

int main(int argc,char *argv[]) {
  char buf[BUF_SIZE];
  FILE *inputFp;
  size_t numRead;

  inputFp = fopen("data.txt", "r");
  if (inputFp == NULL) {
    exit(EXIT_FAILURE);
  }

  while (!feof(inputFp)) {
    numRead = fread(buf, sizeof(char), sizeof(buf), inputFp);
    printf("%ld\t%s", numRead, buf);
  }

  fclose(inputFp);
  exit(EXIT_SUCCESS);
}

可见，文件指针就是FILE结构体的指针，与前两个概念不属于同一层。

当通过文件指针操作文件时，需要调用C语言stdio.h中提供的文件API（c 标准库，fopen()、fread()等），而C标准库最终调用了POSIX的库函数。

并且“file pointer”这个词里的“file”指的是狭义的文件，不包括管道、设备等其他东西，所以单纯用C API只能操作普通文件。

FILE结构体中是包含了文件描述符的，所以C语言也提供了互相转换的方法：

int inputFd;
FILE *inputFp;

inputFd = fileno(inputFp);
inputFp = fdopen(inputFd, "r");

其他问题

系统级别的文件句柄数量限制

虽然说系统内存有多少就可以打开多少的文件，但是在实际实现过程中内核是会做相应的处理的，一般最大打开文件数会是系统内存的10%（以KB来计算）（称之为系统级限制）；

查看系统级别的最大打开文件数如下所示：

~ sysctl -a | grep fs.file-max命令查看
~ cat /proc/sys/fs/file-max
3247469        # 阈值
~ cat /proc/sys/fs/file-nr
# 已分配且使用中 / 已分配但未使用 / 阈值
2976    0   3247469

系统级限制：sysctl命令和proc文件系统中查看到的数值是一样的，这属于系统级限制，它是限制所有用户打开文件描述符的总和；

如果需要临时修改，可以直接向file-max写入新值。永久生效的方法是修改/etc/sysctl.conf：

~ vim /etc/sysctl.conf
fs.file-max = 5242880
# 立即生效
~ sysctl -p

进程级别（用户级别）的文件描述符的限制

内核为了不让某一个进程消耗掉所有的文件资源，其也会对单个进程打开的最大文件描述符做默认值处理（称之为用户级限制）

用户级限制：ulimit命令看到的是用户级的最大文件描述符限制，也就是说每一个用户登录后执行的程序占用文件描述符的总数不能超过这个限制

"too many open files"这条报错信息，它的实际含义是文件描述符数量超限。用​​ulimit -a​​命令打印出各限制值：

~ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127961
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127961
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

其中open files一行就表示当前用户、当前终端、单个进程能拥有的文件描述符的数量阈值（很多文章都描述错了这一点）；

可以用​​ulimit -n [阈值]​​命令来临时修改，退出登录即失效。比如：

ulimit-SHn 10240

 

如果想要永久修改，可以将​​ulimit -n [阈值]​​写入用户的.bash_profile文件或/etc/profile中，也可以修改/etc/security/limits.conf：

~ vim /etc/security/limits.conf
# 用户名 软/硬限制 限制项 阈值
root soft nofile 65535
root hard nofile 65535

文件描述符造成的串话问题

POSIX标准要求每次打开文件时（含socket）必须使用当前进程中最小可用的文件描述符号码。POSIX这种分配文件描述符的方式稍不注意就会造成串话。

串话问题

比如前面举过的例子，一个线程正准备read(2)某个socket，而第二个线程几乎同时close(2)了此socket；第三个线程又恰好open(2)了另一个文件描述符，其号码正好与前面的socket相同（因为比它小的号码都被占用了）。这时第一个线程可能会读到不属于它的数据，不仅如此，还把第三个线程的功能也破坏了，因为第一个线程把数据读走了（TCP连接的数据只能读一次，磁盘文件会移动当前位置）。

另外一种情况，一个线程从fd＝8收到了比较耗时的请求，它开始处理这个请求，并记住要把响应结果发给fd＝8。但是在处理过程中，fd＝8断开连接，被关闭了，又有新的连接到来，碰巧使用了相同的fd＝8。当线程完成响应的计算，把结果发给fd＝8时，接收方已经物是人非，后果难以预料。

解决方法

在C++里解决这个问题的办法很简单：RAII。用Socket对象包装文件描述符，所有对此文件描述符的读写操作都通过此对象进行，在对象的析构函数里关闭文件描述符。这样一来，只要Socket对象还活着，就不会有其他Socket对象跟它有一样的文件描述符，也就不可能串话。剩下的问题就是做好多线程中的对象生命期管理；

重定向标准输出fd，标准错误输出fd的问题

为什么服务端程序不应该关闭标准输出（fd＝1）和标准错误（fd＝2）？因为有些第三方库在特殊紧急情况下会往stdout或stderr打印出错信息，如果我们的程序关闭了标准输出（fd＝1）和标准错误（fd＝2），这两个文件描述符有可能被网络连接占用，结果造成对方收到莫名其妙的数据。正确的做法是把stdout或stderr重定向到磁盘文件（最好不要是/dev/null），这样我们不至于丢失关键的诊断信息。当然，这应该由启动服务程序的看门狗进程完成 ，对服务程序本身是透明的。

总结

 1.  由于进程级文件描述符表的存在，不同的进程中会出现相同的文件描述符，它们可能指向同一个文件，也可能指向不同的文件
 2. 两个不同的文件描述符，若指向同一个打开文件句柄，将共享同一文件偏移量。因此，如果通过其中一个文件描述符来修改文件偏移量（由调用read()、write()或lseek()所致），那么从另一个描述符中也会观察到变化，无论这两个文件描述符是否属于不同进程，还是同一个进程，情况都是如此。
  3. 要获取和修改打开的文件标志（例如：O_APPEND、O_NONBLOCK和O_ASYNC），可执行fcntl()的F_GETFL和F_SETFL操作，其对作用域的约束与上一条颇为类似。
  4. 文件描述符标志（即，close-on-exec）为进程和文件描述符所私有。对这一标志的修改将不会影响同一进程或不同进程中的其他文件描述符