スレッドデッドロックは、マルチスレッドのJavaアプリケーションであれば起こり得るものです。 マルチスレッドのアプリケーションが実装された瞬間から、デッドロック問題が発生する可能性があります。
例えば： アプリケーションを公開リリースに向けて、完全なテスト運用を開始し、追加テストも行い、 最終的に重要な基幹システムとしてデプロイするとします。 アプリケーションの利用が本格的に増して、重要なコンポーネントの応答が突然に止まります。 この時、システム管理者が出来る唯一のことは、システムを再開させるために、アプリケーションを強制終了して再起動させることです。
この障害に伴い、よくあることは、アプリケーションユーザーからシステムの不具合についてのクレームが寄せられ、 営業ロス、その他システムの停滞による損害などを訴えてくることでしょう。 アプリケーションの開発者には、アプリケーションがフリーズしたことが知らされ、即に解決するように言われます。 運悪く、たいていの場合、アプリケーションがフリーズした原因が何か把握することは、ほとんど無理でしょう。 つまり、開発者にとっては、何が原因だったのかヒントもなく、その問題そのものすら把握できないまま、手探り状態で問題を解決しようとしているようなものです。 これは、「もう一度やってみて、どうなるか見てみよう」的な対応になることが多く、誰一人として歓迎するものではないでしょう。
現実の世界においてのアプリケーションで、デッドロック問題を修正することは非常に難しく、症状を再現することはほとんど不可能です。 これは、多くのスレッドが利用されればされるほど、デッドロックが発生する可能性も増える、という現実があるためです。 デッドロックが発生した場所を特定するだけでなく、そこに導いてしまうイベントの組み合わせも検証する必要があり、 ディベロッパー（開発者）にとってみれば、多大な時間を費やします。
Wrapperがデッドロックを検知すると、まず、どのスレッドがどのオブジェクトと絡み合っているか、厳密に詳細ログをとります。
そして、すぐにJVMを再起動させ、最短の停滞時間でシステムをリカバリー（回復）させることができます。
つまり、これで、Javaアプリケーションが稼働可能な状態を維持するだけでなく、
問題を報告するのに必要な全ての情報を残すことができるため、問題修復にも有効です。
デッドロックとは？ |
|
あるプログラムにおいて複数のスレッドが、決して有効にならないオブジェクトへのアクセス待ちが停滞することで、 デッドロックが発生します。 トムとフレッドの２人の例をあげて考えてみましょう。両者は生活のために「物書き」の仕事をしています。 彼らは、ノートとペンを机から持ってきて、物書きを終えたら、ノートとペンを机へ戻す必要があります。 両者はとても強情で、一旦、書き始めると、作業を終えるまでノートとペンを机へ決して戻しません。 トムがノートを取りました、フレッドがペンを取りました、ここで何が起きるでしょうか？ トムはペンが机に戻るのを待ち、フレッドはノートが机に戻るのを待っています。 これが「デッドロック」状態です。 どちらともエンドレスで永久に待ち続けてしまうため、決して前に進むことはありません。 トムとフレッド、どちらかが結局は待ちくたびれて、諦めてノートかペンかを机に戻してくれれば良いのですが、 プログラムの場合、そうはいきません。 デッドロック状況に陥った２つのスレッドがずっと待ち続けることになります。 どこかの時点で、マネージャーがノートがないことに気がつき、これでは問題が起きると察知してくれれば良いのですが。 このようなデッドロック問題の再製や修復が難しくなってしまうのは、単なるタイミングの問題です。 トムとフレッドには、めったに同時に書きものをする必要性が発生しなかったため、 何年間も問題なく共に仕事をしてきました。 しかし、２人が物書きの仕事をする以上、この問題が発生する可能性がすぐに出てきます。 このジレンマをどのように解決すればいいでしょうか？ この問題を解決するためには、 トムもフレッドも、彼らがノートを取ると同時に、常にすぐにペンも取るべきだと理解していればよかったのです。 それでも彼らのどちらかがノートかペンかが机に戻るのを待つ必要があるケースもまだ発生するでしょうが、 エンドレスで永久に停滞してしまうことはありません。 |
ソリューション |
||
|
上記で２人の作業例を挙げたとおり、その原因は明白であり、簡単に解決することができます。 しかしながら、数十個のリソースや何千ものソースコードを持つ非常に大きなアプリケーションソフトにおいて、 問題点を指摘するのは非常に困難であり、その問題を解決することも大変です。 実際のデッドロックでは、いくつかのリソースとスレッドが絡むこともあり、 システム開発者が想定しないような組み合わせが原因で発生することがあります。 テスト環境で問題が見られなくても、そのソフト本質に問題を抱えるデッドロックは、 実際の本稼動で取り扱う現実のデータが大量でサイズも大きく種類も多岐に及ぶため、 本稼動に入ってからデッドロック問題が発生する可能性が非常に高くなるのです。 上記の２人の作業例のように、作業量が少ない場合には、ほとんど問題なくシステムは動作するでしょう。 しかし両者が忙しくなると、問題が発生する可能性が大きくなります。 両者に同じ作業リストを持たせてお互いの仕事（動作）を把握させればいいのですが、 現実には、巨大システムの開発設計において分業作業であるため、両者の動作リストをすり合わせることは困難です。 どちらか１人での作業で問題がなくても、両者が同時に動き出すと、問題が発生するのです。 Java Service Wrapperがアプリケーションレベルのデッドロックの発生を防ぐことができない場合でも、 Wrapperには高度なデッドロック検知機能を装備しているため、 何かがおかしいと人員的な問題察知の前に、Wrapperが問題を検知したり解決します。 同時に、Wrapperは「何が発生したのか」の詳細な情報を収集し、記録をログに残します。 これで、開発者が問題を理解し、問題のあるソース改善に素早く対応することができ、作業が楽になることでしょう。 Wrapperには動作しているアプリケーション全体をモニタリング（監視）機能がありますが、 事実上、何もパフォーマンスに影響を及ぼしません。 アプリケーション内にデッドロックを検知すると、以下のようなWrapperのログファイルでレポートを発行します。
デッドロックが検知された後の処理アクションの実行を、Wrapperに設定することができます。 ほとんどのケースでは、メール通知を送信して、アプリケーションを再起動させることが最良の方法でしょう。 通知メールには、上記の出力が含めるため、わりと簡単に問題を認識でき修復が手軽にできるでしょう。 そして、アプリケーションを再起動させるため、不要な遅延なくリカバリー（回復）でき、ユーザーに与える停滞の影響を最小限に抑えることができます。 まず、レポートを見ることで、「Worker-1」や「Worker-2」スレッドが原因でデッドロックが発生した事実を とても簡単に確認することができ、それぞれの コールスタック内の問題の箇所の正確な場所を把握することもできます。 その出力情報で、どの特定のオブジェクトインスタンスが失敗したのか、さらに明確になります。 なおその上、JVMが自動的に再起動されるため、 ユーザーに与える影響を抑えられ、停滞時間もほんの一瞬で済みます。 Wrapperは次のような様々な危機的な問題の検知に役立ちます： フリーズ、 デッドロック、 クラッシュ、 アプリケーションエラー、 メモリリーク、 JVM終了コードに応答するなど。 |
テクニカルソリューション |
||||||||||||||||||||||||||||||
|
Java Service Wrapperのデッドロック検知機能を有効にする方法は、 ご利用のWrapperコンフィギュレーションファイルに、 ２，３つのプロパティ設定を追加するだけで簡単に実現できます。 Java Service Wrapperに同梱して配布しているTestWrapperサンプルアプリケーションには、 デフォルトでこの機能を有効にしてあります。 単純に、そのアプリケーションを起動して「デッドロック生成」ボタンをクリックすれば、その動作を確認することができます。
|
参照： デッドロック |
|
Java Service Wrapper では、必要なコンフィギュレーション設定を含んだ完全なパッケージを提供しており、 それを活用することで、皆様の求めるニーズに合った動作を実現させることができます。 上記の例の他に、工夫次第で様々なことが実現可能となりますので、それぞれ個別にプロパティページをご覧ください。
|