ある時点でワーカー スレッドを開始するアプリケーションに取り組んでいます。このスレッドの動作は、開始に使用されるパラメーターによって大きく異なりますが、次のプロパティ リストが適用されます。
- いくつかのマイナーな I/O 操作を実行します。
- サードパーティのライブラリで少し時間を費やします
- 特定のサブタスク用にいくつかのワーカー スレッドを作成する場合があります (これらのスレッドは、タスクの終了後に再利用されません)。
- ほとんどの時間を数字の処理に費やします (ブロッキング コールは存在しません)。
長時間 (入力によっては 5 分から数時間) になる可能性があるため、計算を中止できるようにしたいと考えています。中止することを選択した場合、出力を気にする必要がなくなり、スレッドが実行され続ける限り、実際には貴重なリソースが浪費されます。コードは私たちの管理下にあるため、中断を示すために割り込みを使用することをお勧めします。
Web 上のほとんどの例では、何らかのメソッドをループしているワーカー スレッドを扱っていますが、これは私には当てはまりません (同様の質問 here )。また、このワーク スレッドにはブロッキング コールがほとんどないため、この記事では割り込みフラグを手動で確認することをお勧めします。私の質問は次のとおりです。この割り込みを処理するにはどうすればよいですか?
いくつかのオプションがありますが、どれが最も「クリーンな」アプローチであるかを判断できません。私の実際の例にもかかわらず、私はこれに対処する方法に関する「ベストプラクティス」に主に興味があります。
ThreadDeath
ある種のチェックされていない例外をスローします。これにより、スレッドがすばやく簡単に強制終了されますが、非推奨のThread#stop()
メソッドで使用されているアプローチと、それに関連するすべての問題が思い出されます。このアプローチは、(既知のロジック フローにより) 所有コードでは受け入れられますが、ライブラリ コードでは受け入れられないことがわかります。- ある種のチェック例外をスローします。これにより、迅速かつ簡単な方法でスレッドが
ThreadDeath
強制終了され、プログラマーにこのイベントの処理を強制することで、-のような問題が軽減されます。ただし、コードに大きな負担がかかるため、どこにでも例外を記載する必要があります。すべてが . をスローするわけではないのには理由がありますInterruptedException
。 - 「これまでの最良の結果」または空の結果でメソッドを終了します。含まれるクラスの数が多いため、これは非常に難しい作業になります。十分な注意を払わないと、
NullPointerExceptions
結果が空になり、ポイント 1 と同じ問題が発生する可能性があります。これらの原因を見つけることは、大規模なコード ベースではほぼ不可能です。