私のTomcatスタートアップでは、-xms、-xmxを1GBに設定しました。メモリを監視するときのvisualvm内
メモリのサンプリングを行うと、「スナップショット」を押すまで正確なメモリ使用量が表示されません。その後、メモリを利用するJavaクラスが正しいパターンとインスタンスを表示します。なぜこのような？
また、Tomcatのメモリを1 GBに設定すると、メモリはzip-zatを増やし続け、960MBを超えて増加します。「performgc」を押してメモリを200mbに戻すまで。
毎日深夜にjvmでperform.gc（）を強制的にヒットするスケジューラを作成する必要があると思いますか？
私の説明からのコメント
ここに表示されているのは、同時ガベージコレクターが若い世代のクリーンアップを実行していることですが、ヒープは絶えずかき回されているため、古い世代のコレクションのすべての参照を取得することはできません。[GCの実行]ボタンを押すと、すべてのスレッドをブロックし、ヒープをフリーズし、はるかに大きなコレクションを実行できるようにする「stop-the-world」コレクションを実行しています。ここでの私の主な懸念は、大規模なコレクションが（x時間後に）発生することはありますか？ヒープが小さいとOutOfMemoryエラーが発生しますか？
1）自動更新ボタンがオンになっていますか？また、スナップショットを作成する前に、プロファイラーが小さなGC（エデンスペース）を実行する場合もあります。
2）これは完全に正常です。ガベージコレクションには時間とリソース（プロセッササイクル）がかかります。ヒープを大きなサイズに設定した場合、ガベージコレクション自体がトリガーされるまで、ヒープがその一定の割合に達するまで待機します。デフォルトの空き領域とライブオブジェクトの比率は40％から70％の間だと思います。tomcatはバージョン5前後でガベージコレクションの方法を具体的に変更したことを知っています。tomcatv4は、ガベージコレクターの実行に多くの時間を費やしたため、パフォーマンスの問題がありました。ここで調査を行い、tomcatにカスタムのガベージコレクションオプションがあるかどうかを確認することをお勧めします。
3）いいえ。ほぼ完全なヒープがまさにあなたが目指しているものです。完全なガベージコレクションにそれほど時間がかからないように、ヒープを小さくすることは理にかなっています。これは、多数のガベージコレクション（一時停止）と長いガベージコレクション（長い一時停止）の間のトレードオフです。各アプリは異なるので、私は通常、デフォルトから始めて、必要に応じて微調整します。興味があれば、ガベージコレクション（および代替コレクター）には多くのオプションがあります。