首先抛个异常：java.io.FileNotFoundException: (*********)Too many open files。

原因是由于linux限制了一次会话中，程序最大同时打开文件数目。

使用命令查看：

临时修改(退出会话失效)：

永久修改(修改/etc/security/limits.conf文件，设置用户最大打开文件数 )：

注意 nofile 参数在 type 类型上有2个可能的选项：hard 和 soft ，这两个值都需要设置，“-”代表同时设置这2个值为后面的数字。

hard limit 只是作为 soft limit 的上限，soft limit 才是你设置的系统当前限制。当你设置 hard limit 后，soft limit 的值就只能小于 hard limit 。普通用户可以降低 hard limit 的值，但是不能提高它，只有 root 用户才能提高 hard limit。

给个参考版本：

在root用户修改为65536后，用其他用户登录服务器检测ulimit -n 还是1024。那么就是该用户未生效。 ① 解决方案一

使用root用户进行如下操作：

将# UseLogin no修改如下：

重启sshd服务 ：

修改/etc/pam.d/login

修改/etc/security/limits.d/下的配置文件

如下图所示：

② 解决方案二

如果还不行(实际上已经改过来了，只是其他用户看到的是默认值)，建议升级openssh或者重装openssh:

重装openssh如下：

注意，重装ssh会恢复使用默认端口22，如有必要还需修改端口：

如果直接使用其他用户如test登录之后ulimit -n还是1024并且着急使用，那么不妨尝试使用root用户登录然后切换到test用户再操作。

③ 重启ssh服务失败

重启sshd服务可能等待蛮久，然后提示失败。这时候使用命令systemctl status sshd.service查看状态会看到失败，但是毫无有用信息，使用命令journalctl -xe查看会看到异常信息。

异常实例如下：

这里可以进行针对性解决，比如关闭selinux，我这里采用的是重装sshd服务。

① 是什么

ulimit命令用来限制系统用户对shell资源的访问。

解释如下：

假设有这样一种情况，当一台 Linux 主机上同时登陆了 10 个人，在系统资源限制的情况下，这 10 个用户同时打开了 500 个文档，而假设每个文档的大小有 10M，这时系统的内存资源就会受到巨大的挑战，而实际应用的环境要比这种假设复杂的多。

例如在一个嵌入式开发环境中，各方面的资源都是非常紧缺的，对于开启文件描述符的数量，分配堆栈的大小，CPU 时间，虚拟内存大小，等等，都有非常严格的要求。资源的合理限制和分配，不仅仅是保证系统可用性的必要条件，也与系统上软件运行的性能有着密不可分的联 系。这时，ulimit 可以起到很大的作用，它是一种简单并且有效的实现资源限制的方式。

ulimit 用于限制 shell 启动进程所占用的资源，支持以下各种类型的限制：所创建的内核文件的大小、进程数据块的大小、Shell 进程创建文件的大小、内存锁住的大小、常驻内存集的大小、打开文件描述符的数量、分配堆栈的最大大小、CPU 时间、单个用户的最大线程数、Shell 进程所能使用的最大虚拟内存。同时，它支持硬资源和软资源的限制。

作为临时限制，ulimit 可以作用于通过使用其命令登录的 shell 会话，在会话终止时便结束限制，并不影响于其他 shell 会话。而对于长期的固定限制，ulimit 命令语句又可以被添加到由登录 shell 读取的文件中，作用于特定的 shell 用户。

② 语法格式

语法如下：

选项如下：

实例如下：

【Tips】

查看系统可接受的最大打开文件数(一般默认已足够，不用修改)