android exec,关于android：Java Runtime.getRuntime()。exec()在调用它几百次后失败

我有一个执行的Java程序

Runtime.getRuntime()。exec("ls -l");

很多次，一次为系统中的每个目录。

我的测试系统有超过1,000个目录和Runtime.getRuntime()。exec("ls -l"); 似乎在480个目录之后出错了。

我得到的错误消息是"运行exec()时出错。命令：[ls，-l]工作目录：null环境：null"。

我猜它已经耗尽了一些必需的系统资源，或者是吗？

有没有办法处理所有目录而不会出错？

答案的相对评论：

I should clarify that I was using Android SDK's adb.exe. I wanted to

execute something like Runtime.getRuntime().exec("adb shell ls -l")

multiple times on different directories.

它是在某个特定目录上失败还是每次都是一个随机目录？

您可以尝试执行stackoverflow.com/questions/5963741/中列出的答案中的步骤，看看是否有帮助。

随机目录。 列出480个目录后似乎失败了。 失败后，如果我调用Runtime.getRuntime()。exec("ls -l"); 再次没有重新启动程序，它在它看到的第一个目录失败。

您是否在等待每个ls -l进程完成，或者您是否正在并行执行命令？ 有一个Process.waitFor()方法可以确保每个进程都退出。 如果您不等待进程退出，它可能仍在运行，这可能会占用一些系统资源。docs.oracle.com/javase/6/docs/api/java/lang/

嗨，Fly我已经在使用waitFor()了。 感谢您抽出宝贵时间提供帮助。

使用Runtime.getRuntime().exec时，应明确关闭输入/输出流。

Process p = null;

try {

p = Runtime.getRuntime().exec("ls -l");

//process output here

p.waitFor();

} finally {

if (p != null) {

p.getOutputStream().close();

p.getInputStream().close();

p.getErrorStream().close();

}

}

正如Narendra Yadala所说，你明确地关闭了流程的输入和输出流，最好是在最后的块中，但从我的经验来看，仅在这种情况下无法帮助。似乎Linux / Unix中的每进程stdout / stderr -streams都有某种内部缓冲区，当缓冲区填满时，正在运行的进程停止等待某人(即你的Java应用程序)读出数据在它继续之前从那些流中。如果你不这样做，过程就会坐在那里，在某些时候你会耗尽一些系统资源(比如打开文件或格言)

您可能希望将p.destroy()添加到finally列表中。

究竟。如果不关闭流，OP可能会耗尽文件描述符，然后才能耗尽内存。

而不是destroy()进程，我建议使用waitFor()让它们正常完成。使用destroy()"强制终止"该过程，除非您知道该过程不起作用，否则这是一件非常重要的事情。

关闭输入/输出流确实解决了问题。谢谢！

只要p.waitFor()位于非异常路径中，将p.destroy()放在finally列表中可能比关闭每个流更好，除非您还想处理每个close()方法的异常。

最好在这些类上使用java.io.File和适当的方法来遍历和操作文件系统。

您没有说明为什么要以这种方式执行此退化行为，但这是列出树中所有文件的示例。

I have a Java program that executes Runtime.getRuntime().exec("ls

-l"); many times, once for each directory in the system.

为什么？ File.listFiles()出了什么问题？

你甚至不需要执行'ls'。

我应该澄清一下我使用的是Android SDK的adb.exe。我想在不同的目录上多次执行Runtime.getRuntime()。exec("adb shell ls -l")之类的东西。

那么你应该把这个放在问题中，因为你的问题对于你需要得到的答案是不准确的。

@lucky这并没有真正回答这个问题。 Android真的没有java.io.File吗？

Android确实如此。但是，Java应用程序正在运行台式计算机并使用adb.exe与Android设备通信。

@Jarrod Roberson是的，我应该。谢谢。

应该包含在答案中的原因是adb.exe可能是问题的一部分，信息越准确，答案就越准确