历史遗留项目依赖jar过多，在启动时出现too open files异常；
当高并发情况下，用户请求到达服务器之后，Java 应用会打开许多文件，以便读取运行应用程序所必需的类。大量应用程序会使用许多文件描述符，这会导致缺乏新的文件描述符而抛异常。
同样，每个客户端和服务器通过 TCP 套接字连接进行通信，每个TCP套接字连接也都需要一个文件描述符，大量的连接建立也会导致缺乏新的文件描述符而抛异常。
如果你是一位老司机，在高并发访问文件系统，多线程网络连接等场景，常会遇到以下两个异常。
这两个异常都是由超过系统文件描述符限制所产生的，这两个异常明确指出了操作系统 (OS) 资源设置问题或JVM进程限制的问题（直白一点就是文件描述符数过多超过系统或JVM限制无法新建了），当然还有间接导致的的问题，这给我们生产问题排查，增加了不少难度。
这里两个问题都涉及到了文件描述符，那么什么是文件描述符，为什么需要它呢？
在Linux系统中一切皆可以看成是文件，设备是文件，目录是文件，socket 也是文件，用来表示所处理对象的接口和唯一接口就是文件。
应用程序在读 / 写一个文件时，首先需要打开这个文件，打开的过程其实质就是在进程与文件之间建立起连接，文件描述符的作用就是唯一标识此连接。最后关闭文件其实就是释放这个文件描述符的过程，使得进程与文件之间的连接断开。
要了解 Linux 当中的文件描述符，必须先了解 Linux 的文件系统，下图表示了 Linux 的每个进程 (task) 的结构，及 task 所打开的文件的结构。
某日生产服务器发生预警，某某查询服务器大量连接失败，通过CAT监控查看日志发现为Too many open files异常。
奇怪的是只有该服务器出现异常，其它服务器都是正常的，通过netstat -angrep 28503wc -l查看服务器的连接数只有238个。与其他服务器相当。
通过以上对比，发现是在上线时系统优化参数设置遗漏导致的问题。通过修改相关系统参数重启dubbo服务后问题得到临时解决（具体修改参数见后面调优部分介绍）。
其实到这里还没有结束，这个dubbo服务只提供简单的数据查询服务，响应延时低且无积压请求，不应该出现Too many open files问题才对，后来排查发现存在连接泄漏，因为该主题网上已经有人做了详细描述，本文不详细描述。可以参见《侦测程序句柄泄露的统计方法》:了解分析过程。
通过这个案例我想说的是大家在百度上看到的类似问题建议直接修改ulimt -n参数是不全面的，要透过现象多问题几个问题，确保线由Too many open files异常间接引发的问题
通常间接异常难于发现根本原因，下面是我为了复现该问题通过ulimit -n 10手动将最大打开文件数设置为10，引起tomcat启动异常的案例：
系统资源是有限的需要做好容量估算，如linux接受端口和发送端口最大分别为65535个，根据应用和CPU等资源限制，需要依据监控及时横向扩展。
linux系统ext3文件系统的Inodes个数也是有限制的这个和挂在目录大小等有关，在进行大量文件存储时注意做好容量估算。
ext3文件系统一级子目录的个数默认最大为31998个，所以在进行文件保存时要分级目录保存，建议按照业务类型/年/月/日/时/分/秒来保存，当然如果平均每秒新建目录数不超过9个也可以到分钟级别。
因为内核为了不让某一个进程消耗掉所有的文件资源，其也会对单个进程最大打开文件数做默认值处理（称之为用户级限制），默认值一般是1024，使用ulimit -n命令可以查看。
过去是因为服务器紧张，所以单服务器复用，现在为了管理方便和避免复杂度，服务器已经专用和定制化，该参数可以根据实际需要调整，建议修改为40960或者65535。
* soft nofile 40960#限制单个进程最大文件句柄数（到达此限制时系统报警）
* hard nofile 65536 #限制单个进程最大文件句柄数（到达此限制时系统报错）
本文讲了文件操作的概念原理、常见问题及规范，希望通过本文的总结，可以掌握类似问题生产查找方法、熟悉Linux底层机制为进一步系统调优奠定基础，如果你们项目即将上线，那么希望本文的的相关建议可以使你规避类似问题。