java - Java がハングしているように見える

Question

カスタム アプリケーションで Java サービス ラッパーをかなり長い間使用してきましたが、問題なく動作しています。ここ数日でアプリケーションを新しいバージョンに更新してから、JVM がハングし始め、ラッパーがログに次のように出力します。

次に、JVM を自動的に終了し、アプリを再起動します。これは、約 10 時間の実行後に発生するため、デバッグが難しくなります。

もちろん、行った変更に目を通すつもりですが、この種の問題を引き起こしていると思われるような大きな変更は行われていません。

何が起こっているのかを把握するには、どこを参照すればよいですか? アプリケーションからのデバッグ メッセージは、興味深いものを何も示していません。JVM が単にクラッシュした場合、通常はデバッグに役立つダンプが作成されますが、ハングしているため、ダンプは作成されません。サービスを自動的に再起動しないようにした場合、再起動する前に JVM から有用な情報を取得するためにできることはありますか?

私には、JVM が典型的なプログラミング エラーでハングするべきではないように思えます。JVM がハングする原因となる前に、どのようなことに遭遇したことがありますか?

Answer 1

wrapper.ping.timeout プロパティを読んでください。ラッパー ソフトウェアは、JVM が動作していることを確認するために頻繁に JVM と通信します。その通信が何らかの理由で失敗した場合、ラッパーはプロセスがハングしたと見なし、再起動を試みます。

アプリケーションの設計方法によっては、ラッパーが「ping」を実行しようとすると、JVM が他の処理でビジー状態になる場合があります。

Answer 2

Visual VMを使用して何が起こっているかを確認してください。Visual VM でアプリを常に監視し、アプリが動作しなくなったときに何が問題なのかを判断できるようにします。

VM がハングした場合は、スレッドの状態を取得できます... Visual VM は、通常の ctrl-break (またはキーの組み合わせが何であれ) よりもセットアップが少し簡単になると思います。

（コメントに基づいて編集）

これを試しました。前回ハングしたときは、スレッド数と使用中のメモリ量が非常に少なかったため、どちらも問題の原因ではありません。残念ながら、ハングしてラッパーが終了した後は、スレッド ダンプを取得できません。

デバッグするラッパーなしで実行する方法はありますか? また、NetBeans プロファイラーを使用すると、停止したときに対処する機会が得られる可能性があります (今日後で調べて、動作が異なるかどうかを確認できるかどうかを確認します)。

Answer 3

あなたはどのような環境にいますか？OS、JVM バージョン、ハードウェア アーキテクチャは?

これはバグのように聞こえますが、何時間もかかることを考えると、ある種のリソース枯渇バグのように思えます。

Answer 4

クラスパス (JBPM) にいくつかの異なるバージョンのライブラリがありました。ラッパーを使用すると、ワイルドカードを使用して jar を含めることができます。ただし、必要以上に誤って含める可能性があるため、注意してください。

これは、Java でのハングのデバッグに関する情報を提供する IBM の記事です。基本的に、ハングを引き起こす可能性があるのは次の 2 つです。

1. 無限ループ、
2. デッドロック。

それ以来、他のハングアップの問題をデバッグする必要がありました。Linux では、JVM に QUIT シグナルを送信して、コンソールにスレッド ダンプを実行させることができます。これは、問題がどこにあるかを把握するのに非常に役立ちます。これを行うには、次のコマンドを使用します: kill -QUIT

2017 年 6 月 13 日を編集

最近は、JDK に含まれている jmap を使用して、プログラムのメモリ全体をダンプします。次に、Eclipse Memory Analyzer を使用して、プログラムがクラッシュしたときの正確な状態を確認します。アクティブなスレッドのリストを見て、各スタック フレームの変数を調べることができます。

/usr/java/latest/bin/jmap -dump:file=/tmp/app-crash.hprof <PID>

ここで、PID は Java プロセスのプロセス ID です。