Runtime.getRuntime().exec(cmd)使用不当引起的java.io.IOException: Too many open files

本文转自：http://www.blogjava.net/jnbzwm/archive/2010/09/14/332009.html
天生产环境的一个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)这样的调用，那么请确保那段代码没有问题。

本文为原创，欢迎转载，转载请注明出处BlogJava。