現在の世代の JVM で動作するツールやユーティリティを知りません。
しかし、裏を返せば、そのようなユーティリティがどのように役立つかはわかりません。
通常、ヒープがいっぱいになると、長い GC 時間が発生します。ヒープが 100% いっぱいになると、GC で費やされる時間は指数関数的に増加する傾向があります。最悪の場合、ヒープが完全にいっぱいになり、アプリケーションがOutOfMemoryError
. 考えられる解決策は 2 つあります。
どちらの場合も、メモリ プロファイラーを使用すると、問題の分析に役立ちます。ただし、どのオブジェクトが古い世代にあるかを知る必要はありません。問題の根本原因や問題の解決策には関係ありません。
どのオブジェクトの作成を最適化するかを知るために、どのオブジェクトが古い領域に残っている「生存者」であるかを知りたいです。
これはもう少し理にかなっています。具体的にどの空間に住んでいるかではなく、どのオブジェクトが長命であるかを見つける必要があるようです。jhat
一連のヒープスナップショットを比較するために使用することで、それを行うことができます。(もっと良い方法があるかもしれません...)
しかし、私はまだこのアプローチが役立つとは思わない。問題は、完全な GC がすべての到達可能な (ハード、ソフト、ウィーク、ファントム) オブジェクトをトラバースする必要があることです。また、30% がいっぱいの 32Gb ヒープがある場合、マーク/スイープ/再配置するオブジェクトがまだたくさんあります。解決策は、並行コレクターを使用して、アプリケーションのオブジェクト割り当て率に追いつくことができるように調整することである可能性が高いと思います。
System.gc()
また、コードから直接 呼び出しているようにも思えます。そうしないでください! を呼び出すSystem.gc()
と、(通常) JVM は完全なガベージ コレクションを実行します。それはあなたに一時停止を与えることがほぼ保証されています. コレクターをいつ実行するかを決定するために JVM を残す方がはるかに優れています。
最後に、「オブジェクト作成の最適化」が何を意味するのかが不明です。オブジェクトの作成速度を下げるということですか? それとも、長期間存続する (キャッシュされた?) オブジェクトの保持を管理するために何か他のことを考えていますか?