如果进程以退出代码0结束,我应该调用Process.destroy()吗?

时间:2016-04-11 21:09:17

标签: java process runtime.exec exit-code

我有一个通过Spring JMSListener启动的进程。该过程基本上运行Runtime exe来调用imagemagick来对图像进行一些重新处理。在* nix下,即使Runtime exec命令以退出代码0退出并且没有抛出异常,也会保留线程。该应用正在使用Gythio Runtime Exec类来执行其工作。尽管Gythio正确处理的Runtime可能会出现StdErr和StdOut周围常见的陷阱,但即使它成功了,我们也不应该破坏这个过程吗?

这是一个简单的例子,请忽略代码错误,它不是真正的代码。我的问题围绕//进程完成块:

public class Test {

    public void doSomething(String cmd, String processProperties, String processDirectory){

        try {
            // cmd is something like convert ... file .. params

            Runtime runtime = Runtime.getRuntime();

            final Process process = runtime.exec(cmd, processProperties, processDirectory);

            int exitValue = process.waitFor();

            System.out.println("exit value: " + exitValue);
            BufferedReader buf = new BufferedReader(new InputStreamReader(
                    process.getInputStream()));
            String line = "";
            while ((line = buf.readLine()) != null) {
                System.out.println("exec response: " + line);
                //log = line;
                //writeToFile(line);
            }
            // process is done... should it be destroyed? 
            if(process != null){
                process.destroy();
            }
            // end process done
        } catch (Exception e) {
            System.out.println(e);
        }
    }
}

运行大约一个小时后,在tomcat中运行的应用程序会显示这些线程(其中tomcat是pid 1641):

[root@server logs]# top -H -p 1641
top - 19:45:24 up 264 days, 10:33,  4 users,  load average: 0.00, 0.00, 0.19
Tasks: 5068 total,   0 running, 5068 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  1.5%sy,  0.0%ni, 97.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8061332k total,  6690912k used,  1370420k free,   195348k buffers
Swap:  1888252k total,    77672k used,  1810580k free,  5070148k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1734 adminuser  20   0 5842m 948m  13m S  0.3 12.0   3:03.41 java
1641 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.00 java
1643 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:01.20 java
1644 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:02.31 java
1671 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:02.28 java
1678 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:02.35 java
1686 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:02.20 java
1687 adminuser  20   0 5842m 948m  13m S  0.0 12.0   2:25.66 java
1688 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.11 java
1691 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.08 java
1706 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.00 java
1712 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:53.24 java
1720 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:39.38 java
1721 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:12.96 java
1722 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.00 java
1723 adminuser  20   0 5842m 948m  13m S  0.0 12.0   2:54.47 java
1724 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.00 java
1728 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:03.62 java
1729 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:08.16 java
1731 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.75 java
1732 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:02.58 java
1735 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:03.63 java
1736 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:02.23 java
1737 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:00.92 java
1738 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:03.59 java
1739 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:02.96 java
1740 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:05.07 java
1741 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:02.26 java
1742 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:04.57 java
1743 adminuser  20   0 5842m 948m  13m S  0.0 12.0   3:01.79 java
1744 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:26.27 java
1745 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.10 java
1746 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:10.72 java
1747 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.00 java
1748 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:10.99 java
5611 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.68 java
5620 adminuser  20   0 5842m 948m  13m S  0.0 12.0   0:00.36 java

感谢任何/所有回复!提前谢谢!

1 个答案:

答案 0 :(得分:0)

我怀疑你的程序正在创建一个非平凡的输出。当您在后台运行程序时,它将写入缓冲区大小,可能只有几KB。达到缓冲区大小后,等待消费者(程序)读取输出。这适用于标准输出和错误。

如果您没有消耗输出和错误,您生成的程序可能会永远等待,但您正在等待退出代码,这将不会发生,因此您会遇到死锁。

我建议您使用ProcessBuilder,将错误重定向到输出,并在等待退出代码之前将其读取到结尾。

来自示例。

ProcessBuilder pb = new ProcessBuilder("myCommand", "myArg1", "myArg2");
pb.redirectErrorStream(true);
File log = new File("log");
pb.redirectOutput(Redirect.appendTo(log));
Process p = pb.start();
// no need to copy the output
int exit = p.waitFor();