维基百科：
文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。
作用：可以用在FileInputStream的构造参数上
文件描述符：
文件描述符就是内核为了高效管理已被打开的文件所创建的索引，用来指向被打开的文件，所有执行I/O操作的系统调用都会通过文件描述符。程序刚刚启动的时候，0是标准输入，1是标准输出，2是标准错误。如果此时去打开一个新的文件，它的文件描述符会是3。POSIX标准要求每次打开文件时（含socket）必须使用当前进程中最小可用的文件描述符号码，因此，在网络通信过程中稍不注意就有可能造成串话。标准文件描述符图如下：
文件描述与打开的文件对应模型如下图：
系统为了维护打开的文件，会维护三个表，分别是：
进程级的文件描述符表
系统级的文件描述符表
文件系统的i-node表 (转到：阮一峰——理解inode)
进程级的描述符表的每一条目记录了单个文件描述符的相关信息。
- 控制文件描述符操作的一组标志。（目前，此类标志仅定义了一个，即close-on-exec标志）
- 对打开文件句柄的引用
内核对所有打开的文件的文件维护有一个系统级的描述符表格（open file description table）。有时，也称之为打开文件表（open file table），并将表格中各条目称为打开文件句柄（open file handle）。一个打开文件句柄存储了与一个打开文件相关的全部信息，如下所示：
当前文件偏移量（调用read()和write()时更新，或使用lseek()直接修改）
打开文件时所使用的状态标识（即，open()的flags参数）
文件访问模式（如调用open()时所设置的只读模式、只写模式或读写模式）
与信号驱动相关的设置
对该文件i-node对象的引用
文件类型（例如：常规文件、套接字或FIFO）和访问权限
一个指针，指向该文件所持有的锁列表
文件的各种属性，包括文件大小以及与不同类型操作相关的时间戳
下图展示了文件描述符、打开的文件句柄以及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()调用。同一个进程两次打开同一个文件，也会发生类似情况。
前人的思考，我们的阶梯，这部分参考自网络：链接
文件描述符限制
有资源的地方就有战争，“文件描述符”也是一种资源，系统中的每个进程都需要有“文件描述符”才能进行改变世界的宏图霸业。世界需要秩序，于是就有了“文件描述符限制”的规定。
如下表：
永久修改用户级限制时有三种设置类型：
soft指的是当前系统生效的设置值
hard指的是系统中所能设定的最大值
-指的是同时设置了 soft 和 hard 的值
命令讲解:
检查某个进程的文件描述符相关内容
步骤(以nginx为例，*注意权限问题，此示例是在本地环境)：
找到需要检查的进程id:
如图，找到的进程id为 1367
查看该进程的限制:
如图，在 Max open files 那一行，可以看到当前设置中最大文件描述符的数量为1024
查看该进程占用了多少个文件描述符:
如图所示，使用了17个文件描述符
总结
实际应用过程中，如果出现“Too many open files” , 可以通过增大进程可用的文件描述符数量来解决，但往往故事不会这样结束，很多时候，并不是因为进程可用的文件描述符过少，而是因为程序bug，打开了大量的文件连接（web连接也会占用文件描述符）而没有释放。程序申请的资源在用完后及时释放，才是解决“Too many open files”的根本之道。
————————————————
版权声明：本文为CSDN博主「cywosp」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
