本文出处: http://www.blogjava.net/jnbzwm/archive/2010/09/14/332009.html

</p>

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)这样的调用,那么请确保那段代码没有问题。

</p>

</span></span>

转载请注明:WebLogic Android 博客 » Runtime.getRuntime().exec(cmd)使用不当引起的java.io.IOException: Too many open files[转]