Javaがハングしているようだ

Question

私はかなり長い間カスタムアプリケーションでJava Serviceラッパーを使用してきましたが、うまくいきました。ここ数日でアプリケーションを新しいバージョンに更新して以来、JVMはハングアップを開始し、ラッパーはこれをログに出力します。 JVMがハングアップしているように見えます：JVMからの信号待ちでタイムアウトしました。

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

私が行った変更を見ていきますが、このタイプの問題の原因と思われる大きな変更はありませんでした。

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

JVMが典型的なプログラミングエラーからハングしてはいけないと思う。これまでにJVMをハングさせる原因は何ですか？

Answer 1

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

ここには、debugging hangs in Javaに関する情報を記載したIBMの記事があります。

1. 無限ループ、
2. デッドロック：それは基本的にハングアップを引き起こすことができる2つのものがあることを述べています。

その後、私は他の懸案事項をデバッグしなければなりませんでした。 Linuxでは、QUITシグナルをJVMに送信して、コンソールにスレッド・ダンプを実行させることができます。これは実際に問題がどこにあるかを把握するのに役立ちます。それを行うには、このコマンドを使用します。-QUIT

編集2017年6月13日

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

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

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

Answer 2

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

これはバグのように聞こえ、何時間もかかるとすれば、何らかの資源枯渇バグのように聞こえます。

Answer 3

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

アプリケーションのアーキテクチャーによっては、ラッパーが「ping」しようとしたときにJVMが別の処理を実行している可能性があります。

Answer 4

Visual VMを使用して何が起こっているかを確認してください。 Visual VMにアプリケーションを常時監視させて、おそらく何が間違っているかを判断することができます。

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

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

はこれをしようとしました。最後にスレッド数が で、使用メモリ量が と非常に少ないので、 のいずれも、 の問題を引き起こしていません。残念ながら、それがハングアップした後に とラッパーはそれを終了させることはできません スレッドダンプを取得します。

ラッパーなしで実行する方法はありますか？また、NetBeansプロファイラを使用している場合は、停止時に対処するチャンスが与えられます（今日後でチェックし、違う動作をするかどうか確認してください）。