到達不能なオブジェクトをGCするのにJVMを長く使うのはなぜですか？

Question

私はアプリケーションでクラスローダーのリークに取り組んでおり、最終的にCLへのすべての参照がなくなったということになりました。私のメモリプロファイリングツール（YourKitとjmap/jhatを使用）では、時々すぐにクラスローダーを取り除くGCを強制することができますが、それ以外の時間（アプリケーションの使用状況にもよりますが、 GC、CLインスタンスは消えません。私は、メモリスナップショットをキャプチャし、結果を見て、それはこのオブジェクトが存在するが、到達不能であると言います。

ここは変わった部分です...私はこれを偶然発見しました。

私は完全にGCを強制することができますが、インスタンスは離れません。しかし、10〜20分後にもう一度完全なGCを実行すると、はになります。うまくいけば

（この間アプリケーションは）ない全く（ほとんどは非アクティブです。私の「拡張」のコーヒーブレークは、この発見につながった事故だった。）

だからここにリークについての私の懸念は消えました（ ）、しかし問題は今、この振る舞いを説明しようとしています。

Sun JVMが到達不能なクラスローダーを20分間収集しないことを知っている人は誰でも知っていますか？

日JVMのバージョンの詳細：クラスローダ（とクラス：

java version "1.6.0_23" 
Java(TM) SE Runtime Environment (build 1.6.0_23-b05) 
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) 

Answer 1

そうなJVMただの推測をgenerationalガベージコレクションを使用しますが、最終的にはフルマークアンドスイープに

Answer 2

を行うだろうので、ロードされている）は、通常のヒープにはなく、永続的な世代（PermGen）にあります。通常の状態では、クラスローダーが範囲外にならないので、メモリのこの部分は他のものよりもずっと少ない頻度でスワイプされます。

（この頻度に影響するいくつかのGC設定オプションがあるかもしれません）。私は、PermGenを塗りつぶしてそこにコレクションをトリガーすると思いますが、通常はこれをしたくありません。

実際にあなたのクラスローダーを収集する必要があるのはなぜですか？

Answer 3

私はジェレミー・ヘイラーがファイナライズ上の問題で正しいトラックにいると思います。基本的には、GCが到達不能であることが分かっていても、オブジェクトが実際に収集されるまでにはまだ不確定な時間である可能性があります。ファイナライザスレッドは、オブジェクトをファイナライズするために回り込む必要があります（ファイナライズする必要がある他のオブジェクトの数とファイナライザの外観によっては時間がかかることがあります）。オブジェクトがファイナライズされた後は、 別の GCは、オブジェクトが実際に収集される前に到達不能であることを再発見します。

さらに、Sun JVM上のClassLoaderの場合、PermGenに直接割り当てられている可能性があります。ですから、2個の完全なPermGenスイープ（1つはオブジェクトをファイナライゼーションキューに入れてから、もう1つは実際にそれを収集する）です。 PermGen掃引は高価なので、Sun JVMはデフォルト設定ではまったく実行しないと思います。さまざまなGCチューニングを行っても、PermGenを掃除するのは非常に嫌です（特に、 ）。

そうではなく、あなたが何かを行う場合は、何 System.gc()を使用してGC（ええと、私は意味、 はを奨励）強制の：もちろん

System.gc(); 
System.runFinalization(); 
System.gc(); 

を、でもこれは動作が保証されていませんが、大規模なファイナライズが必要なオブジェクトをクリーンアップするためには、少なくとも最小限の作業を行います。

Answer 4

可能な理由は、クラスローダをソフト参照によって保持されたことです。

-XX:SoftRefLRUPolicyMSPerMB=1 

で実行してみてください、それは違いを作るかどうかを確認します。それはmy caseで起こったことです。