JVM パラメータのチューニングの概要
では JVM起動時のパラメータは、デフォルト設定のJVMに関連するガベージコレクションは、何か良い仕事をしませんが、いくつかの良いServerの構成と、特定のアプリケーションのために慎重に得るには調整する必要があり、メモリといくつかのパラメータを設定することができます最適なパフォーマンス。我々はいくつかの目標を設定することで実現したいと考えています：
- GC時間が十分に小さいです
- 以下のGC十分な数
- これは、発生したフルGC（新しい中生代と古い年サイクル）十分な長さ
最初の二つがために、現在反する小型の十分な数を確保するために少し小さいヒープ、GCでなければなりませんGC時間、私たちは、より大きなヒープが、我々は唯一のバランスを選択することができるようにする必要があります。
（ 1）-Xms -Xmxその最小値、最大値、最小値の間に収縮ヒープガベージコレクタを防ぐために、最大の追加の時間が生成され、我々は通常、最大、最小セットで一般的に、JVMスタックのために提供される定義同じ値（ 2）と、既定の比率に応じて、古い世代の若い世代：ヒープメモリが割り当てられる（12）は、それらの間に2つのNewRadioのサイズ比を調整することによって調整することができ、また、置換のために回収することができますこのよう-XXによって若い世代として：NewSizeパラメータ-XX：その絶対サイズMaxNewSizeを設定します。同様に、ヒープの若い世代の収縮を防ぐために、我々は通常、-XXます：NewSizeパラメータ-XX：MaxNewSizeは、同じサイズに設定しました
（ 3）は、若い世代と旧世代セットはどのくらい合理的ですか？私は、そうでなければ、チューニングはないであろう、この質問が未回答である疑いはありません。私たちは、両方の大きさの変化の影響を見て
- 大きな若い世代が必然的に小さく古い世代につながる、大きな若い世代は、通常の拡張されます GCをGCサイクルを、しかしたびに増加します。小さな古い世代は、より頻繁に全GCにつながります
- 小さい若い世代は、必然的に、より古い世代につながる、若い世代には、小さな共通につながる非常に頻繁にGCが、すべての時間は、GC時間が短くなります。大規模な高齢者世代は、フルGCの頻度を減らします
- どのようにアプリケーションオブジェクトのライフサイクルの分布に依存すべき選択するには：アプリケーションが一時オブジェクトが多い場合は、より大きな若い世代を選択する必要があります。永続オブジェクトの比較的大きな数がある場合は、古い世代は、適切に増加する必要があります。しかし、多くのアプリケーションが選択に、このような明確な特徴は、以下の2点:(に基づくべきではありません 2真実である：1のJVMのデフォルトのスケール、可能な共通オブジェクトキャッシュ限り、旧世代がそうすることを、AのできるだけわずかのフルGCの原則） 1：アプリケーションの期間を観察することにより、（B）、旧世代のピーク時に他の全GCに影響を与えずに、実際の状況の若い世代を増やすどのくらいのメモリ、を占めることになる参照、例えば、1の割合で制御することができます。しかし、古い世代に成長の余地の少なくとも1/3を残す必要があります