缘由：前几天再不是服务的时候，发现项目启动的时候日志不动了，查了半天发现是打开文件最大数没有设置，然后就上网看了相关的资料，也整理了一些网上的总结思想。
到底最大文件数被什么限制了？
too many open files错误到底可以通过什么参数控制？
一、shell级限制
通过ulimit -n修改，如执行命令ulimit -n 1000，则表示将当前shell的当前用户所有进程能打开的最大文件数量设置为1000.
用户级限制
ulimit -n是设置当前shell的当前用户所有进程能打开的最大文件数量，但是一个用户可能会同时通过多个shell连接到系统，所以还有一个针对用户的限制，通过修改 /etc/security/limits.conf实现，例如，往limits.conf输入以下内容：
root soft nofile 1000
root hard nofile 1200
soft nofile表示软限制，hard nofile表示硬限制，软限制要小于等于硬限制。上面两行语句表示，root用户的软限制为1000，硬限制为1200，即表示root用户能打开的最大文件数量为1000，不管它开启多少个shell。
系统级限制
修改cat /proc/sys/fs/file-max
但是呢，有很多很重要的细节，有很多错误的描述
限制当前shell以及该shell启动的进程打开的文件数量。为什么大家会觉的是限制单个线程的最大文件数量，因为很多情况下，在一个shell环境里，虽然可能会有多个进程，但是非常耗费文件句柄的进程不会很多，只是其中某个进程非常耗费文件句柄，比如服务器上运行着一个tomcat，那么就是java进程要占用大多数文件句柄。此时ulimit设置的最大文件数和java进程耗费的最大文件数基本是对应的，所以就会这样觉得。
还有，很多文章称ulimit -n 只允许设置得越来越小，比如先执行了ulimit -n 1000，在执行ulimit -n 1001，就会报"cannot modify limit: Operation not permitted"错误。这个其实也是不准确的说法。首先要搞清楚，任何用户都可以执行ulimit，但root用户和非root用户是非常不一样的。
非root用户只能越设置越小，不能越设置越大
我在机器上以非root先执行：
[wxx@br162 etc]$ ulimit -n 900
[wxx@br162 etc]$
执行成功，再增大：
[wxx@br162 etc]$ ulimit -n 901
-bash: ulimit: open files: cannot modify limit: Operation not permitted
[wxx@br162 etc]$
增加失败，如果减少则是OK的：
[wxx@br162 etc]$ ulimit -n 899
[wxx@br162 etc]$
如果再增加到900是不行的：
[wxx@br162 etc]$ ulimit -n 900
-bash: ulimit: open files: cannot modify limit: Operation not permitted
[wxx@br162 etc]$
root用户不受限制
首先切换到root：
[wxx@br162 etc]$ sudo su -
[root@br162 ~]#
查看下当前限制：
[root@br162 ~]# ulimit -n
1000000
[root@br162 ~]#
增大：
[root@br162 ~]# ulimit -n 1000001
[root@br162 ~]#
可以成功增大，再减小：
[root@br162 ~]# ulimit -n 999999
[root@br162 ~]#
减小也是成功的，再增大：
[root@br162 ~]# ulimit -n 1000002
[root@br162 ~]#
也是ok的，可见root是不受限制的。
ulimit里的最大文件打开数量的默认值
如果在limits.conf里没有设置，则默认值是1024，如果limits.con有设置，则默认值以limits.conf为准。例如我换了一台机器，登录进去，ulimit -n显示如下：
[root@zk203 ~]# ulimit -n
2000
这是因为我的limits.conf里的文件打开数是2000，如下：
[root@zk203 ~]# cat /etc/security/limits.conf
root soft nofile 2000
root hard nofile 2001
如果limits.conf里不做任何限制，则重新登录进来后，ulimit -n显示为1024。
[root@zk203 ~]# ulimit -n
1024
ulimit修改后生效周期
修改后立即生效，重新登录进来后失效，因为被重置为limits.conf里的设定值
二、/etc/security/limits.conf
网上有的文章显示，ulimit -n设定的值不能超过limits.conf里设定的文件打开数（即soft nofile）
好吧，其实这要分两种情况，root用户是可以超过的，比如当前limits.conf设定如下：
root soft nofile 2000
root hard nofile 2001
但是我用root将最大文件数设定到5000是成功的：
[root@zk203 ~]# ulimit -n 5000
[root@zk203 ~]# ulimit -n
5000
[root@zk203 ~]#
但是非root用户是不能超出limits.conf的设定，我切换到wxx，执行命令如下：
[wxx@zk203 ~]# ulimit -n 5000
-bash: ulimit: open files: cannot modify limit: Operation not permitted
[wxx@zk203 etc]$
所以网上的说法是错误的，即使非root用户的最大文件数设置不能超过limits.conf的设置，这也只是一个表象，实际上是因为，每个用户登录进来，ulimit -n的默认值是limits.conf的 soft nofile指定的，但是对于非root用户，ulimit -n只能越来越小，不能越来越大，其实这个才是真正的原因，但是结果是一样的。
三、/proc/sys/fs/file-max
网上说，ulimit -n 和limits.conf里最大文件数设定不能超过/proc/sys/fs/file-max的值，这也是搞笑了，/proc/sys/fs/file-max是系统给出的建议值，系统会计算资源给出一个和合理值，一般跟内存有关系，内存越大，改值越大，但是仅仅是一个建议值，limits.conf的设定完全可以超过/proc/sys/fs/file-max。
[root@zk203 ~]# cat /proc/sys/fs/file-max
1610495
我将limits.conf里文件最大数量设定为1610496，保存后，打印出来：
[root@zk203 ~]# cat /etc/security/limits.conf
root soft nofile1610496
root hard nofile1610496
四、结合相关文章总结
/proc/sys/fs/file-max限制不了/etc/security/limits.conf
只有root用户才有权限修改/etc/security/limits.conf
对于非root用户， /etc/security/limits.conf会限制ulimit -n，但是限制不了root用户
对于非root用户，ulimit -n只能越设置越小，root用户则无限制
任何用户对ulimit -n的修改只在当前环境有效，退出后失效，重新登录新来后，ulimit -n由limits.conf决定
如果limits.conf没有做设定，则默认值是1024
当前环境的用户所有进程能打开的最大问价数量由ulimit -n决定