部分内容摘抄自 https://blog.csdn.net/qq_18581221/article/details/80963741
一、问题的基本描述、原因、解决方案
出现这个错误原因是打开文件数（Linux一切皆文件，所以打开文件数包含文件和Socket连接数）超过Linux设置的最大数；
二、实际遇到的案例
1. 问题分析
以上内容都是摘抄自上面的博文；大概描述了下问题，我这边就不做自行描述了，也提供了一些利用配置的解决方案；
下文我这边会举一个实际场景遇到的问题，进行排查分析；
too many open files, 如果是真的资源需要这么多，提供修改配置是可以解决的；
但是我们要考虑一种句柄泄漏的情况；比如下述案例：
某服务宕机出现的too many open files 的报错。
重启下服务就好了；有其他同事已调整过句柄参数，比如unlimit这些，但是后面几天该服务还是出现了一样的问题；
说明了什么？
说明了无论你调整为多大，随着服务的运行，句柄数始终是会吃完的；那么就是程序存在这种句柄泄漏；比如 文件流没关闭，socket没关闭等；类似于数据库连接泄漏，connection没关闭；类似于redis连接没关闭等造成的泄漏；
如何排查：
直接将当时的句柄使用情况打印出来，查看句柄占用情况，lsof >a, 即将linux服务器的句柄使用情况打印到a文件；
如图，基本上是 mobile.properties 这个文件导致的，说明某个地方打开了这个文件，但是IO流程并没关闭，导致的句柄泄漏；
而我们的报错信息正好是涉及mobile.properties这个文件的，当然这个地方是巧合，可能是这个地方的文件读的相对频繁，其他的文件没读，甚至么有，所以刚刚好这个报错体现出来； 假设一个系统的运行可能无时无刻的都在打开文件 关闭文件，那么一旦句柄泄漏完了，可能会出现各种各样的报错，并不会让我们查到报错就是涉及这个文件的；
那我们进一步查看上述代码的堆栈，发现，fis首先是没有关闭，且最安全的方式是finnally里面关闭；
这个地方fis重复引用也是文件，会导致泄漏；
2. 解决方案：
上述代码修复关闭即可；