巨大な webapp を使用して、しばらくの間 Java 1.4 で Tomcat 5.5 を実行しています。ほとんどの場合、正常に動作しますが、例外が生成されず、Tomcat を再起動する以外に再度実行する明白な方法がないままハングすることがあります。tomcat インスタンスは、ヒープ上で 1 ギガバイトのメモリを使用できますが、300 MB を超えることはめったにありません。他の誰かがこの問題に遭遇しましたか?解決策はありますか?
明確にするために、タスクマネージャーとEclipseを介して使用しているメモリの量を決定しました（Eclipseの外部でも実行しようとしましたが、最終的には同じ問題が発生しますが、少し時間がかかります）。Eclipse では、小さな (オプションの) メモリ ペインを介して割り当てられたメモリと、タスク マネージャを介して javaw.exe に割り当てられた量を確認します。私はシスデオを使用しますか？Eclipse 用の Tomcat プラグイン。
すべての jvm プロセスに対して、スレッド ダンプを強制します。Windows では、これはコンソール ウィンドウで CTRL-BREAK を使用して実行できると思います。
*nix では、ほとんどの場合「kill -3 jvm-pid」です。
これは、db 接続プール/スレッド プールなどで待機しているスレッドがある場合に表示されることがあります。
チェックアウトするもう 1 つのことは、JVM への現在の接続数です。NETSTAT または tcpconn/tcpview (google it) などの SysInternals ユーティリティを使用します。
また、verbose:gc JVM フラグを指定して実行してみてください。Sun の JVM の場合は、「java -verbose:gc」のように実行します。これにより、ガベージ コレクションが表示されます。大量に収集している場合 (特に FULL COLLECTIONS)、メモリ リークが発生している可能性があります。完全なコレクションは、特にそのような大きなヒープではコストがかかります。
300MB しか使用されていないことをどのように判断していますか?
Tomcat アプリケーション サーバーのログの感度を上げてみてください。 http://tomcat.apache.org/tomcat-5.5-doc/logging.html
数日間、感度を FINEST または ALL に上げて、それが何かをキャッチするのに役立つかどうかを確認してください。
デッドロックに陥っているようですね。
開発環境で再現できる場合は、一度デバッガをアタッチしてみてください。スレッドを見て、デッドロックがないかどうかを確認してください。
ダスティンが指摘したように、デバッガーをアタッチできない場合は、スレッド ダンプを生成できるはずです。
複数のスレッド ダンプを作成して表示することに同意します: Thread Dump Analyzer