まず、JVMのチューニングは何ですか？
いわゆるJVMのチューニングは、Java仮想マシンのヒープメモリサイズの調整を指します。そして、メモリの設定はどのようにそれを設定していること？セットには、はるかにパフォーマンスに影響を与えることなく、メモリの無駄、適切でありませんか？
分析：原理はJavaのパフォーマンス内部の式に従って設定することが勧告に基づいています。
具体的に：
セット全体のJavaヒープサイズは、XmxのとのX msは3~4倍のメモリがFullGC後歳で占められていること、3〜4回、オブジェクトの生存歳に設定しました
永久に代わっPermSizeをとMaxPermSizeのは、古い時代に1.2〜1.5倍の生存オブジェクトを設定します。
1-1.5歳の倍のため、若い世代の設定された目標のXMN生存。
旧のメモリサイズは、古い時代に2-3回生存オブジェクトを設定されています。
説明：
1、Sunの関係者は、若い世代のサイズは、Sunの勧告に沿ったもので、その上で述べたようにし、スタック全体のおよそ3/8で示唆されました。
2、若い世代のヒープサイズ=旧世代のサイズ+サイズ、Xmxの= XMN +歳サイズ。PermSizeをは、ヒープサイズには影響を与えません。
3、なぜそれが上記来るに応じて設定すべきか？具体的な説明はないが、それは、様々なチューニングによると結論した後でなければなりません。
第二には、どのようにオブジェクトの古いサイズの生存を確認するには？
モード1（推奨/より安全）：
JVM引数は、GCでログインの追加、GCログは歳GCの後にスペースを観察し、各FullGC後のメモリサイズの各世代を記録します。メモリは、データの何倍サイズの後に古い時代の空間記憶によると、多くのFullGC後（FullGC老齢後に生き残った（例えば2日間など）一定期間後にFullGCの状況を観察することができ、オブジェクトのサイズを推定するためにFullGCサイズ）、平均
モード2 :(必須トリガーFullGCは、注意して、オンラインサービスに影響を与えます）
1より実現可能な方法が、JVMパラメータを変更し、ログを分析する必要があります。CMSコレクタを使用した場合、ログがFullGCロギングが行われないので、また、、FullGC（のみ起こるCMS GC）がトリガされない場合があります。これは、分析の際にハンドルがより困難です。
だから、時には我々は、FullGCオブジェクトのサイズの後の古い生存を観察するために、FullGCトリガーを強制する必要があります。
注：必須トリガーFullGC、オンラインサービスには気をつけて、一時停止（STW）を引き起こすだろう、それは、最初のサービスノードは、その後、ハングバックサービス利用可能なノードFullGC後、外部サービス必須FullGC前に除去される操作の推奨モードです
FullGCは、複数のFullGCオブジェクトのサイズを生き残った後歳推計によるFullGCの古いメモリ状況の後、異なる時間でトリガ
第三には、どのようにFullGCをトリガーするには？
FullGCをトリガすることができますjmapの使用ツール
jmapの-dump：ライブ、フォーマット= B、ファイル= heap.bin <PID>その後、FullGCトリガ、ファイルに現在のライブオブジェクトをダンプします
jmapの-histo：ライブ<PID>メモリフットプリントの各クラスのインスタンス数を表示し、オブジェクトクラス番号情報.liveのサブパラメータの完全な名前がプラス、この時期だけのライブ統計がFullGCをトリガーします。
IVの概要
比較的タイトなメモリの場合の方法は、上述したメモリチューニングすることができるでは、メモリは、GCおよびGCがかかる上許容される周波数のセットを見つけるために、現在のサービスの必要性、より少ないメモリを満たすことができ
しかし、メモリは比較的裕福で、彼らは少しより多くのメモリよりもサービスに比べ増加させることができ、GCの頻度を減らすことができ、GCは、時間のかかる対応の数が増加します。
上述のように低レイテンシのための一般的要件が厳しい少ない遅延に配置されたマルチビットメモリと考えることができる、より少ないメモリを設けてもよいです。
追加：若い世代は、記事が古い世代+ +永続的な世代の記述が誤っている記述読む前に永久世代（ゾーン法）がスタックしていないので、=全体のヒープサイズがあります。