ScheduledExecutorServiceでスケジュールされたタスクインスタンスの取得

Question

JEE環境でのタスクスケジューリングのためにScheduledExecutorServiceを取得しました。これらのタスクの中には、中断されたときにリソースが開かれているものがあります（例えば、Luceneのようなサードパーティのライブラリを開いたファイル）。ScheduledExecutorService.shutdownNow()

私はスレッドが自分自身の実行を止めることはできないことを知っています：スレッドを停止するために使用される方法は、割り込みフラグを頬を傾けてメソッドの実行を停止し、スレッドがブロック（例えばwait（）、sleep ）など）、または割り込み可能なチャネルでIO操作を行っている場合、Thread.interrupt()はInterruptedExceptionを立ち上げます。どちらの場合も、finallyブロックを実行する必要があります。 参照：http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Thread.html#interrupt%28%29。明らかに、私はすでにタスククラスのfinallyブロックでリソースを解放しようとしましたが、いくつかの環境（例えばCentOS）ではスレッドが中断したときfinallyブロックは実行されません。そして、私は公式のJavaドキュメントには、この非常にクールなノートを見つけた：

注：試してみるか、キャッチコードが実行されている間、JVMが終了した場合、 finallyブロックが実行されないことがあります。同様に、tryまたはcatchコードを実行しているスレッド が中断または終了した場合、アプリケーション全体が として継続しても、最後に ブロックが実行されないことがあります。

私が必要とするのは、リソースの解放を強制するタスククラスにいくつかのパブリックメソッドを実装するためにスケジュールされたすべてのタスクへの参照です。 ScheduledExecutorServiceからタスククラスへの参照を取得できますか？または、私の問題をより良い方法で解決するための素晴らしいアイデアがありますか？

最初の解決策：それをラップしてください！

ScheduledExecutorServiceのラッパークラスを作成し、このようなプロパティを追加します。それに

private IdentityHashMap<ScheduledFuture<?>, Runnable> taskList; 

を私たちが直接任意のRunnableオブジェクトにアクセスする、またはそれに関連するScheduledFutureですることができます。ラッパーのインスタンス化のために、私はExecutors.newScheduledThreadPool()メソッドからScheduledExecutorServiceを取得し、それを私のラッパーに渡すことができます。

もう1つ解決策：それを拡張してください！

ScheduledThreadPoolExecutorを拡張し、IdentityHashMapプロパティを追加して、ジョブのスケジュールまたはキャンセル方法をすべて上書きして、マップから参照を追加または削除します。

両方のソリューションに問題がありますか？

ラッパーまたは拡張クラスの呼び出し元がSchedulerFuture<?>オブジェクトを受け取った場合は、「カプセル」をバイパスしてSchedulerFuture<?>.cancel()メソッドでジョブをキャンセルすることができます。ラッパーを使用すると、呼び出し側にSchedulerFuture<?>参照を渡すことは避けられますが、拡張クラスを使用することはできません（拡張クラスで独自のメソッドを作成すると、ラッパーと同じ結果が得られますが、非常に混乱します）。

エレガントなソリューション：独自のスケジューラ！カジュに感謝しています...

1. 実際 スレッドをキャンセルするだけでなくへRunnableオブジェクトを操作するのカスタムcancel()方法を実装 ScheduledFutureインタフェース
2. の一の実装でRunnableを飾る decorateTask()方法
3. を上書きするScheduledThreadPoolExecutorを拡張リソース解放のために を強制してください。

詳細とコードの例については、postをご覧ください。

Answer 1

あなたは何を予定していますか？タスクはどのように見えますか？私はfinallyブロックが実行されないと信じることは非常に難しいと感じています。私はあなたがスケジューリングしたタスクだと推測しますが、リソースが漏れているため実行し始めていません（最終ブロックは実行されないため）

CentOS上のVM実装が本当に悪いようです実際には最終的にブロックを実行していません。他のVMの実装でそれについて聞いたことはありません。

スケジューリングされたすべてのタスクを参照するのではなく、ScheduledThreadPoolExecutorをサブクラス化してdecorateTaskメソッドをオーバーライドして、クラスでタスクをデコレートし、キャンセル呼び出しをインターセプトすることができます。