文件描述符fd

java 后台运行程序命令

nohup java -jar babyshark-0.0.1-SNAPSHOT.jar  > log.file  2>&1 &

   命令解释：后台启动一个程序命令：nohup command &

   以上命令中：> log.file指的是将命令执行生成的数据重定向到log.file中，即文件描述符标准输出（1）指向的是log.file,（2）表示错误信息输出，2>&1代表将错误输出重定向到标准输出，即错误输出和标准输出一起都在标准输出中，而标准输出在之前已经重定向到了log.file中了，所以该命令表示后台启动一个程序，并且该程序的标准输出和错误输出都指向了log.file这个文件。

  转载于：https://www.itqiankun.com/article/file-fd

 什么是文件

 　　Linux 下，一切皆文件

在Linux操作系统中，可以将一切都看作是文件，包括普通文件，目录文件，字符设备文件（如键盘，鼠标…），块设备文件（如硬盘，光驱…），套接字等等，所有一切均抽象成文件，提供了统一的接口，方便应用程序调用

文件描述符

既然在Linux操作系统中，你将一切都抽象为了文件，那么对于一个打开的文件，我应用程序怎么对应上呢？

文件描述符应运而生

文件描述符：File descriptor,简称fd，当应用程序请求内核打开/新建一个文件时，内核会返回一个文件描述符用于对应这个打开/新建的文件，其fd本质上就是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

文件描述符的工作流程

系统为了维护文件描述符建立了3个表

进程级的文件描述符表

系统级的文件描述符表

文件系统的i-node表

操作系统为每一个进程维护了一个文件描述符表，该表的索引值都从从0开始的，所以在不同的进程中可以看到相同的文件描述符，这种情况下相同的文件描述符可能指向同一个文件，也可能指向不同的文件，具体情况需要具体分析，下面用一张简图就可以很容易的明白了

在进程A中，文件描述符1和30都指向了同一个打开的文件句柄（#23），这可能是该进程多次对执行打开操作

进程A中的文件描述符2和进程B的文件描述符2都指向了同一个打开的文件句柄（#73），这种情况有几种可能:

1.进程A和进程B可能是父子进程关系;
2.进程A和进程B打开了同一个文件，且文件描述符相同（低概率事件=_=）；
3.A、B中某个进程通过UNIX域套接字将一个打开的文件描述符传递给另一个进程。

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

总的来说就是：

应用程序进程拿到的文件描述符ID == 进程文件描述符表的索引，通过索引拿到文件指针，指向系统级文件描述符表的文件偏移量，再通过文件偏移量找到inode指针，最终对应到真实的文件

在进程A中，文件描述符1和30都指向了同一个打开的文件句柄（#23），这可能是该进程多次对执行打开操作

进程A中的文件描述符2和进程B的文件描述符2都指向了同一个打开的文件句柄（#73），这种情况有几种可能:

1.进程A和进程B可能是父子进程关系;
2.进程A和进程B打开了同一个文件，且文件描述符相同（低概率事件=_=）；
3.A、B中某个进程通过UNIX域套接字将一个打开的文件描述符传递给另一个进程。

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

总的来说就是：

应用程序进程拿到的文件描述符ID == 进程文件描述符表的索引，通过索引拿到文件指针，指向系统级文件描述符表的文件偏移量，再通过文件偏移量找到inode指针，最终对应到真实的文件

所以linux下两个进程返回的文件描述符是不一样的

多个进程之间的fd：

1.两个进程中分别产生生成两个独立的fd
2.两个进程可以任意对文件进行读写操作，操作系统并不保证写的原子性
3.进程可以通过系统调用对文件加锁，从而实现对文件内容的保护
4.任何一个进程删除该文件时，另外一个进程不会立即出现读写失败
5.两个进程可以分别读取文件的不同部分而不会相互影响
6.一个进程对文件长度和内容的修改另外一个进程可以立即感知

文件描述符限制

文件描述符是一个重要的系统资源，理论上系统内存多大就应该可以打开多少个文件描述符，但是实际情况是，内核会有系统级限制，以及用户级限制（不让某一个应用程序进程消耗掉所有的文件资源，可以使用ulimit -n 查看）。

检查某个进程的文件描述符

以nginx为例，首先找到需要检查的进程id，找到的进程id为 1367

查看该进程的限制，如图，在 Max open files 那一行，可以看到当前设置中最大文件描述符的数量为1024

查看该进程占用了多少个文件描述符，如图所示，使用了17个文件描述符