1

WAV を MP3 に順次変換するバッチ プロセスがあります。問題は、数千の後、開いたままのファイルが多すぎて、ファイルの制限に達してしまうことです。

これを行う理由は、SystemCommandTasklet のコードのためです。

FutureTask<Integer> systemCommandTask = new FutureTask<Integer>(new Callable<Integer>() {
    public Integer call() throws Exception {
        Process process = Runtime.getRuntime().exec(command, environmentParams, workingDirectory);
        return process.waitFor();
    }
});

これには、JVM に依存してプロセスをクリーンアップしたり、ファイルを開いたままにしたりするという厄介な副作用があります。

私はそれを次のように書き直しました：

FutureTask<Integer> systemCommandTask = new FutureTask<Integer>(new Callable<Integer>() {
    public Integer call() throws Exception {
        Process process = Runtime.getRuntime().exec(command, environmentParams, workingDirectory);
        int status = process.waitFor();

        process.getErrorStream().close();

        process.getInputStream().close();

        process.getOutputStream().flush();
        process.getOutputStream().close();

        process.destroy();

        return status;
    }

});

これが私の mac で動作することは 95% 確信していますが (lsof のおかげで)、どのシステムでも動作する適切なテストを作成して、実行しようとしていることが実際に動作していることを証明するにはどうすればよいでしょうか?

4

3 に答える 3

1
  1. プロセスは JVM に接続されていないため、そのために Runtime#exec() を使用しないでください。JVM のプロセスによって制御されるプロセスを返す jlProcessBuilder を見てください。そのため、プロセスをダンプすると、システムがリソースを解放/クローズすることが強制される場合があります。
  2. jucExecutors を使用して、プロセスもスケジュールおよび制限する必要があります。
  3. また、「ulimit -Sn」を使用して制限を読み取ることもできます (「ulimit -Hn」は、システムの健全性のために優先されるべきではありません;)。
  4. メディアを変換するツールを確認して、完了後にリソースが予約されているかどうかを確認します (リーク、発信者信号の待機など)。
于 2010-08-27T20:15:31.967 に答える
0

立証は難しいでしょう。しかし ...

本物と同じように、あまり機能しないがファイルのロックを保持する (ダミー) コマンドを作成します。これにより、テストが使用される実際のコマンドに依存しないことが保証されます。

古いバージョンの DummyCommand を使用して、SystemCommandTask を開始するテストを作成します。予想される例外が発生するまで、タスクを頻繁に開始します。必要なタスクの数を呼び出しましょう N

100xN タスクを開始するようにテストを変更します。

タスクを新しいバージョンに変更します。テストが緑色になった場合、コードが機能することを合理的に確認する必要があります。

于 2010-08-27T19:38:34.190 に答える
0

それを回避するためにコーディングを試みることができます。

一度に 100 などのタスクの数を積極的に制限してみませんか?

その場合、いくつかのプーリングメカニズムを使用して、スレッドプールのように機能することができます。

于 2010-08-27T19:19:07.903 に答える