プロセスが終了コード0で終了する場合、Process.destroy（）を呼び出す必要がありますか？

Spring JMSListenerで開始されるプロセスがあります。プロセスは基本的にランタイムEXEを実行して、イメージの再処理を行うためにイメージ・マジックを起動します。 * nixでは、実行時execコマンドが終了コード0で終了し、例外がスローされなくても、スレッドが残っています。アプリはGythio Runtime Execクラスを使用して作業を実行しています。 Gythioが正しく処理しているRuntimeで発生する可能性のあるStdErrとStdOutの通常の落とし穴にもかかわらず、成功したにもかかわらずプロセスを破壊すべきではないでしょうか？プロセスが終了コード0で終了する場合、Process.destroy（）を呼び出す必要がありますか？

単純な例ですが、実際のコードではないコードエラーは無視してください。私の質問は、//プロセスで行わブロックの周りです：実行中のおよそ時間後

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である）、これらのスレッドを示しています

[[email protected] 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

どれ/すべての返信は高く評価されています！前もって感謝します！

出典

2016-04-11 Griff

ストリームを閉じた場合（リソースを試してみるなど）、それらはクリーンアップされますか？ –

あなたはそれが必要であるとは思わないでしょう。プロセスが 'exit（）'を呼び出した、またはmainから返された終了コードを返した場合、プロセスを破棄する必要はありません。 – EJP

プログラムが終了してプログラムが終了するまで、プログラムは終了できません（または終了コードを返します）。 –

私はあなたのプログラムが重要でない出力を生成していると思われます。バックグラウンドでプログラムを実行すると、わずか数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();

出典

2016-04-12 07:39:23

この例は、単に私がクラスhttps://github.com/Alfresco/gytheio/blob/master/gytheio-commons/src/main/java/org/gytheio/util/exec/RuntimeExec.javaがprocess.destroy（）が必要です。あなたがクラスを見ると、libはstd outとerrorsを消費しているので、私はそれを考えません。私は上記の@EJPのコメントに同意する傾向があります。しかし、ありがとう！ – Griff

@Griffコードはあなたの質問のものとは非常に異なっています。 –

プロセスが終了コード0で終了する場合、Process.destroy（）を呼び出す必要がありますか？

答えて

関連する問題