G1コレクターを使用したときにJVM（ホットスポット）がメモリリークする問題が発生したことはありますか？
ヒープサイズを60GBに固定しました（-msと-msの両方が60Gに設定されています）が、Javaプロセスのサイズ（psコマンドのvsz列による）は約64GBから始まりますが、84GBに増加します7時間以内。
並列コレクターを使用すると、プロセスサイズは20時間の実行にわたって安定し、約65GB程度になります。
他の誰かがG1コレクターで同様の問題を抱えていましたか？私は非常に単純なベンチマークを実行しており、直接バッファメモリやその他のオフヒープメモリ（私が知っている）を使用していません。
Javaのバージョンは1.7.0、アップデート5です。
（私はこれについてOracleにバグを提起しましたが、誰かが回避策を持っている場合に備えて、ここでもチェックすると思いました）。
G1コレクターで同様の問題を抱えた人はいますか?
まもなく - はい。
これは、メモリリークの原因に関する SO トピックです。
G1に関する情報が含まれています
InflaterInputStream を使用して c-tor (たとえば PNGImageDecoder) で new java.util.zip.Inflater() を渡し、インフレータの end() を呼び出しません。まあ、c-tor を new だけで渡した場合、可能性はありません...そしてそうです、ストリームで close() を呼び出しても、c-tor パラメータとして手動で渡された場合、インフレータは閉じません。ファイナライザーによって解放されるため、これは真のリークではありません...必要と判断された場合。その瞬間まで、ネイティブ メモリを大量に消費するため、Linux oom_killer が問題なくプロセスを強制終了する可能性があります。主な問題は、Java でのファイナライズが非常に信頼性が低く、G1 によって 7.0.2 まで悪化したことです。話の教訓: できるだけ早くネイティブ リソースをリリースします。ファイナライザーはあまりにも貧弱です。
リークはここでも言及されています: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152954