1

バグが原因で、単純な/消耗可能なスレッドが継続したいスレッドでデッドロックされている長時間実行プロセスがあるため、別の方法では再現が難しい最終レポートを実行できます。

もちろん、将来の実行のためにバグを修正することは、適切な最終的な解決策です。もちろん、そのようなスレッドの強制的な割り込み/強制終了/停止は本質的に安全ではなく、他の予測できない不整合を引き起こす可能性があります。(私はすべての標準的な警告とその理由を熟知しています。)

それでも、唯一の代替手段はJVMプロセスを強制終了し、より長い手順を実行することであり、最終レポートの完成度が低下するため、面倒/非推奨/危険/危険/1回限りの手法がまさに私が望むものです試してみる。

JVM は Ubuntu 上の Sun の 1.6.0_16 64 ビットであり、消耗スレッドはオブジェクト モニターのロックを待機しています。

正確なスレッドに向けられた OS シグナルは、消耗スレッドで InterruptedException を作成できますか?

gdb でアタッチし、JVM データを直接改ざんしたり、JVM プロシージャを呼び出したりすると、消耗スレッドが保持するオブジェクト モニタを強制的に解放できますか?

Thread.interrupt()別のスレッドからの aInterruptedExceptionは、ロック待機中のフレームからaを生成しますか? (少し努力すれば、実行中のシステムに任意の Beanshell スクリプトを挿入できます。)

Thread.stop()JMXまたはその他のリモートインジェクションメソッドを介して非推奨を送信できますか?

どんなアイデアでも、「危険」であればあるほど良いのです! そして、あなたの提案が同様の状況での個人的な経験でうまくいったなら、最高です!

4

2 に答える 2

2

正確なスレッドに向けられた OS シグナルInterruptedExceptionは、消耗スレッドに を作成できますか?

いいえ。

gdb でアタッチし、JVM データを直接改ざんしたり、JVM プロシージャを呼び出したりすると、消耗スレッドが保持するオブジェクト モニタを強制的に解放できますか?

理論的にはそうです。実際に成功するには、JVM の内部構造を深く理解する必要があります。だから、現実的にNo.

Thread.interrupt()別のスレッドからの aInterruptedExceptionは、ロック待機中のフレームからaを生成しますか? (少し努力すれば、実行中のシステムに任意の Beanshell スクリプトを挿入できます。)

理論的にはそうです。実際には、beanshell スクリプトはスレッドを中断するためのオブジェクトを見つける必要があります。Threadこれには、オブジェクトのツリーのトラバースThreadGroupなどが含まれる場合があります。別の問題は、中断されたスレッドが適切に動作するかどうかです。たとえば、多くの人が待機/通知コードを作成して、キャッチ/無視InterruptedExceptionして再試行します。それを行った場合、割り込みはおそらく何の役にも立たないでしょう。

非推奨の Thread.stop() を JMX またはその他のリモート インジェクション メソッド経由で送信できますか?

呼び出すThread.interrupt()ことができる場合は、同じアプローチを使用してを呼び出すことができますThread.stop()。普通はやらないと言ってます。しかし、この状況では試してみる価値があるかもしれません。

しかし、これらすべてから得られる本当の教訓は、応答を生成するのに数日または数週間かかる可能性のあるアプリケーションは、この種の不測の事態、および電源障害、ハードウェア障害、マシンの再起動などに対処するためのチェックポイント/再開メカニズムを実装する必要があるということです。等

于 2010-05-06T04:06:40.827 に答える
0

忘れてください。最良のケースでは、何らかのウォッチドッグ タイマーによってデッドロックを検出し、スタックしているスレッドを無視し、新しいスレッドを作成して作業を続行できます。あまり満足できません。関連するロックを解除できず、2 つ (またはそれ以上) のロックが保持されています。「消耗品」スレッドが保持しているロックを解放することはできません。

潜在的なデッドロックを検出するかなり簡単な方法があります。各ロックに 1 から上のレベルを割り当てます。「ロックを保持している間、スレッドはより低いレベルのロックのみを取得する必要がある」というルールを適用します。ルール違反を見つけた場合は、番号付けを修正します。修正できない場合は、デッドロックが発生する可能性があり、運が悪いと実際のデッドロックになる可能性があります。コードを変更してください。

于 2014-02-24T23:11:58.303 に答える