java.io.IOException: Too many open files

一、问题：上传的图片产生很多size为0的图片
二、错误日志：
（1）tomcat日志
StandardWrapperValve[default]: Servlet.service() for servlet default threw exception
java.io.IOException: Too many open files
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
（2）应用日志
com.jspsmart.upload.SmartUploadException: File can't be saved (1120).

三、技术实现：利用jspsmart上传原始图片，再用Runtime.getRuntime().exec(cmd)执行ImageMagick进行图片缩小和加水印的处理。该应用环境为windows，tomcat

四、解决过程
根据参考一对日志一分析后得出打开的文件句柄过多，而且没有得到释放，当超过OS文件句柄数时则会产生这个error。根据参考二对源码进行了改进。代码从原来：

public void exec(String cmd) throws Exception{
  try{
      Runtime.getRuntime().exec(cmd).waitFor();
  }
  catch(Exception exception){
      exception.printStackTrace();
      throw exception;
  }
}

改为

public void exec(String cmd) throws Exception{
  Process process = null;
  try
  {
    process = Runtime.getRuntime().exec(cmd); 
    int result = process.waitFor();  
  }
  catch(Exception exception)
  {
    exception.printStackTrace();
    throw exception;
  }finally{
    if (process != null) process.destroy(); 
  }
}

参考一:http://www.blogjava.net/fly2008/archive/2009/08/26/292626.html

今天后台服务器（Linux） 在转音源的时候 报java.io.IOException: Too many open files
在网上查了一些资料 记录如下：

打开的文件过多，一般来说是由于应用程序对资源使用不当造成，比如没有及时关闭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

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

参考二：http://www.blogjava.net/jnbzwm/archive/2010/09/17/332009.html

Runtime.getRuntime().exec(cmd)使用不当引起的java.io.IOException: Too many open files
今天生产环境的一个Java应用程序的日志里，出现了很不和谐的记录：
java.io.IOException: Too many open files

在网上查了一些关于此异常的解决方案，基本上都是说要扩大linux系统的文件句柄数限制。
但如果程序对于Socket、Stream等使用后没能及时关闭的话，扩大这个文件句柄数限制是治标不治本的。

我先是在测试环境扩大了linux的文件句柄数限制，随后提高测试压力，过一段时间后发现还是会报这个异常。
（中间也用lsof命令查看占用的文件句柄数，不断的增加啊，心寒啊。）
现象是 用 lsof -p *** 来查看，形如
java 22055 webapp 21w FIFO 0,6 29300342 pipe
java 22055 webapp 22r FIFO 0,6 29256305 pipe
在不断增加。

所以我果断对代码进行了排查。文件的IO操作、对数据库的操作，看了都没有什么问题，
最后排查到由Java程序去调用Shell脚本的代码，

代码写的还是很简单的，看上去很清晰，但是有明显的问题：

Process proc = Runtime.getRuntime().exec(cmd);
//略对proc.getErrorStream()、proc.getInputStream()流的操作。
proc.waitFor();
return proc.exitValue();

这里的问题是 对流没有在finally处做关闭处理。这个问题比较明显。
还有一个问题就是Process的使用问题，

如果对Process的不熟悉的话，可能会以为return proc.exitValue();之后就万事大吉了。
（exitValue()确实很像是已经退出了并得到返回值的意思，估计是这个方法的名字迷惑了我们的开发人员。）
实际不然，看Jdk的帮助文档可以发现，要通过destroy()来实现对子进程的销毁并释放占用的File Descriptor。

这个问题，短时间的测试是不会有问题的，但在投入生产后，随着程序的长期运行，开发中的疏忽就会暴露了。
所以在对使用的方法拿不准的情况下，还是要多做调查，谨慎使用啊。

希望能让在排查类似问题的朋友注意，如果你排查的代码中也存在Runtime.getRuntime().exec(cmd)这样的调用，那么请确保那段代码没有问题。