初めて NetBeans のプロファイラーをチェックしています。今朝、Monitor プロファイラーを介して 1700 を超える生存世代が表示されていることに気付きましたが、ヒープサイズは一定です。いくつか読んでいると、NetBeans プロファイラーを使用してリークを発見する方法について説明しているこの記事を見つけました。
そこで、記事のアドバイスに従って、メモリ プロファイラーを開始しました。結果を見ると、char[] が生き残った世代の大部分を占めていることがわかりました。現在、この投稿の時点で、char[] は 22 世代であり、数えています。
現在、いくつかの投稿 (下部近くの OldCurmudgeon によるコメント)は、私のヒープが安定していればリークがないことを示していますが、世代が成長し続ければリークがあると言う人もいます。だから、どちらが正しいのか少し混乱しています。
だから、私の質問は：
次のスクリーン ショットに基づいて、潜在的なメモリ リークをさらに調査する必要がありますか?
メモリ(ヒープ)
メモリー(GC)
ライブ割り当てオブジェクト
はchar[]おそらくStringオブジェクトによって保持されます。プロファイラーと JMX がそれらを使用するなど、目的を問わずどこにでも作成できるため、何もしないプロセスはこれら (および成長するヒープ) を表示します。
注: すべての文字列リテラルとクラスの名前などは、ClassLoader がアンロードされるまで存続します (これはプログラムの寿命になる可能性があります)。
ヒープ使用量が増加しているかどうかを判断するには、完全な GC 後に保持される量を確認する必要があります。各ディップの底を見てください。私には同じように見えます。その他の情報はパフォーマンス チューニングに役立ちますが、それ自体は問題ではありません。
また、プロファイリング中にこれらの長引く char[] に直面しました。長い分析の結果、これらの多くは String 定数プールの char 配列であるという結論に達しました。
コードを見ないとわかりません。TB のメモリを使用するプログラムがありますが、これはメモリ リークではなく、プログラムの動作に問題がないため、問題なく動作します。
Netbeansのドキュメントでは、生き残っている世代を定義しているだけであり、その数値を使用してメモリ リークを特定する方法は定義していません。さらに、 achar[]は a の単なるコンテンツでありString、非常に長い時間 (メインスレッドと同じくらい) 保持できます。
リークを見つける特効薬はありません。実行可能な負荷の下でプログラムを実行し、メモリ使用量が予想されるパターンと一致しているかどうかを確認する必要があります。そうでない場合、問題がありますが、そのグラフは何の意味もありません。