Linux环境出现java.net.SocketException: 打开的文件过多错误

报此错误是由于系统内核对进程打开文件个数的限制，默认为1024 
[root@localhost ~]# ulimit -n 
1024 

修改参数，增大这个限制： 
  
#vi /etc/security/limits.conf 
  
增加下面这一行内容： 
  
  *                -       nofile          65535 
将限制增加到65535 

  注意"nofile"项有两个可能的限制措施。就是项下的hard和soft。 要使修改过得最大打开文件数生效，必须对这两种限制进行设定。 如果使用"-"字符设定, 则hard和soft设定会同时被设定。 
  硬限制表明soft限制中所能设定的最大值。 soft限制指的是当前系统生效的设置值。 hard限制值可以被普通用户降低。但是不能增加。 soft限制不能设置的比hard限制更高。 只有root用户才能够增加hard限制值。 

重启机器使修改配置生效 

[root@localhost ~]# ulimit -n 
65535 

------------------------------------- 
为什么发生此问题？ 

这些异常指出操作系统 (OS) 资源问题和操作系统与 JVM 进程用完文件描述符的原因（请参阅什么是文件描述符？） 

在几个并发用户连接到服务器之后通常会发生此问题。Java 打开许多文件，以便读取运行应用程序所必需的类。大量应用程序会使用许多文件描述符，这会导致缺乏新的文件描述符。同样，每个新的套接字都需要一个描述 符。客户端和服务器通过 TCP 套接字进行通信。在与服务器建立连接时，每个浏览器的 http 请求都使用 TCP 套接字。 

一定要首先监视文件描述符并了解这些诊断方法如何告知您有关打开文件的状态和其它潜在问题。在针对操作系统逐步执行此故障排除部分之后，可能有必要增加文件描述符的数量 
监视文件描述符 

解决方法指导原则 
下面是一般指导原则和考虑事项： 
确定文件描述符的总数是否太少或者某些文件描述符是否未被正确释放。 
这可以通过以下方法来诊断：在不同的时期检查文件描述符的总数，确定此数量是有所减少还是一直增加。 
如果此数量有所减少，则应当增加文件描述符的最大数量，以防止该问题再次发生（如何在不同平台上定义文件描述符的数量）。 
此变化可以和减少连接在断开之前保持 TIME_WAIT 状态的时间结合起来（如何以及何时发布文件描述符？）。在繁忙的服务器上，缺省值（240 秒）会延迟其它连接企图，从而将限制最大连接数量。 
如果此数量一直增加，则应当确定某些描述符的处理时间是否过长（文件没有正确地关闭 - 如何以及何时发布文件描述符？）以及所创建的文件是否过多（例如，驱动程序库一直为每个新的 JDBC 连接加载文件）。 
加载 jar 文件还可能减少所使用的文件描述符的数量。每个 jar 文件都使用一个描述符，即使每个单独加载的单一类都将使用一个描述符时也是如此。 
您可以使用下列指导原则来监视和诊断所有描述符如何由一个进程使用（这取决于您的操作系统）： 

检查打开的文件 

Unix 平台 
在诸多工具中，lsof (LiSt Open Files) Unix 管理工具（适用于 Solaris、Tru64、HP-UX、Linux 和 AIX）显示有关打开文件和网络文件描述符的信息，包括它们的类型、大小和 i-节点。 

对于特定的进程，其语法如下所示： 


lsof -p <进程的 pid>

转载地址：http://jsx112.iteye.com/blog/935509

******永久性做法

为了使服务器重启设置还能生效， 采取永久改变的方法。

vim /etc/security/limits.conf

在文档最后添加

* soft nofile 65535
* hard nofile 65535

(2) vim  /etc/pam.d/login

在文档最后添加

session required /lib/security/pam_limits.so

从另一个 网站找到了  说法。。觉得 这个说法 更标准

打开的文件过多，一般来说是由于应用程序对资源使用不当造成，比如没有及时关闭Socket或数据库连接等。但也可能应用确实需要打开比较多的文件句柄，而系统本身的设置限制了这一数量。
异常 1 
java.net.SocketException: Too many open files

    at java.net.PlainSocketImpl.accept(Compiled Code)
    at java.net.ServerSocket.implAccept(Compiled Code)
    at java.net.ServerSocket.accept(Compiled Code)
    at weblogic.t3.srvr.ListenThread.run(Compiled Code)

异常 2
java.io.IOException：打开的文件过多

    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.(UNIXProcess.java:54)
    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.(UNIXProcess.java:54)
    at java.lang.Runtime.execInternal(Native Method)
    at java.lang.Runtime.exec(Runtime.java:551)
    at java.lang.Runtime.exec(Runtime.java:477)
    at java.lang.Runtime.exec(Runtime.java:443)

...

第一个异常在错误影响到基础 TCP 协议时抛出，而第二个异常则在错误影响到 I/O 操作时抛出。

文件打开数过多最坏的情况可以使系统崩溃，到时候只能是重起服务器了。

原因:  

    操作系统的中打开文件的最大句柄数受限所致，常常发生在很多个并发用户访问服务器的时候.因为为了执行每个用户的应用服务器都要加载很多文件(new一个socket就需要一个文件句柄),这就会导致打开文件的句柄的缺乏.

解决:

尽量把类打成jar包,因为一个jar包只消耗一个文件句柄,如果不打包,一个类就消耗一个文件句柄.
java的垃圾回收不能关闭网络连接打开的文件句柄,如果没有执行close()(例如:java.net.Socket.close())则文件句柄将一直存在,而不能被关闭.你也可以考虑设置socket的最大打开数来控制这个问题.
 对操作系统做相关的设置,增加最大文件句柄数量。
Linux
在 Linux内核2.4.x中需要修改源代码，然后重新编译内核才生效。编辑Linux内核源代码中的 include/linux/fs.h文件，将 NR_FILE 由8192改为65536，将NR_RESERVED_FILES 由10 改为 128。编辑fs/inode.c 文件将MAX_INODE 由16384改为262144。或者编辑 /etc/sysctl.conf  文件增加两行 fs.file-max = 65536 和 fs.inode-max = 262144 。一般情况下，系统最大打开文件数比较合理的设置为每4M物理内存256，比如256M.可以用lsof -p <pid of process>看打开的文件句柄数.
Windows
最大文件句柄是16,384,你在任务管理器的性能这一项中可以看到当前打开的句柄数.

服务器端修改：

查看系统允许打开的最大文件数

#cat /proc/sys/fs/file-max

 

查看每个用户允许打开的最大文件数

ulimit -a

发现系统默认的是open files (-n) 1024，问题就出现在这里。

在系统文件/etc/security/limits.conf中修改这个数量限制，

在文件中加入内容：

* soft nofile 65536
* hard nofile 65536

 

另外方法：
1.使用ps -ef |grep java   (java代表你程序，查看你程序进程) 查看你的进程ID，记录ID号，假设进程ID为12
2.使用：lsof -p 12 | wc -l    查看当前进程id为12的 文件操作状况
    执行该命令出现文件使用情况为 1052
3.使用命令：ulimit -a   查看每个用户允许打开的最大文件数
    发现系统默认的是open files (-n) 1024，问题就出现在这里。
4.然后执行：ulimit -n 4096
     将open files (-n) 1024 设置成open files (-n) 4096

这样就增大了用户允许打开的最大文件数