6

hibernate 3.6.4 と spring 3.2.4 (mvc、tx および security) を使用する Web アプリケーションがあり、Tomcat 7 で実行されています。Tomcat を再起動せずにアプリの新しいバージョンをデプロイするたびに、 tomcat は約 50MB 増加します。

いくつかのヒープ ダンプを作成し、Eclipse メモリ アナライザーで分析しました。アプリを再デプロイするたびに、WebappClassLoader の新しいインスタンスが作成されることがわかりました。しかし、Tomcat マネージャーでアプリケーションを停止した後でも、WebappClassLoader はメモリ内に残り、ガベージ コレクションは行われません。そのため、再デプロイするたびに追加の WebappClassLoader がメモリに残り、約 50MB のメモリを使用します。

WebappClassLoader から GC ルートへの参照パスを見つけるために、Eclipse メモリ アナライザーを使用しました。その結果、WebappClassLoaders がガベージ コレクションされるのを防ぐ可能性のある強力な参照を見つけることができませんでした。

ここに画像の説明を入力

では、何が WebappClassLoaders を存続させているのでしょうか? WebappClassLoader がガベージ コレクションから妨げられている原因を見つけるために、他にどこを調査できますか?

GC がガベージ コレクションを終了できないようにするブロッキング finalize() メソッドがあるのではないかと考えました。しかし、どうすればこれを確認できますか？

4

3 に答える 3

6

クラスローダーは、オブジェクトインスタンスへの参照がなく、クラスのアンロードが不要な場合、理論上はガベージコレクションされますが、実際にはもっと問題があるようです。

この2つの記事を読むことをお勧めします

http://frankkieviet.blogspot.com.au/2006/10/classloader-leaks-dreaded-permgen-space.html

http://frankkieviet.blogspot.com.au/2006/10/how-to-fix-dreaded-permgen-space.html

于 2015-11-24T16:02:06.243 に答える
0

私は Tomcat の専門家ではなく、これは再デプロイの実装ですが、JBoss を使用していた頃は、まったく同じような状況でした。これは、PermGen スペースがガベージ コレクションされておらず、新しい展開ごとにそこにクラスが配置されるためです。したがって、Java 8 を使用していない場合は、実際の「リーク」が permgen スペースにないかどうかを確認してください。

于 2015-11-27T11:31:28.897 に答える