JVM を学ぶのは難しいですか?それは記事を注意深く読んでいないからです。

1: 仮想マシンのメモリ図

JAVA プログラムは仮想マシン上で実行され、実行時にメモリ領域を必要とします。仮想マシンが JAVA プログラムを実行すると、管理しやすいように管理するメモリが異なるデータ領域に分割されます。

[[238454]]

仮想マシン管理メモリデータ領域は以下のように分割されています。

データ領域の分類:

方法領域

VMスタック

ネイティブメソッドスタック

ヒープ

プログラムカウンタレジスタ

直接記憶

例:

1. プログラムカウンタ

行番号インジケータ、バイトコード命令の分岐、ループ、ジャンプ、例外処理、スレッド回復 (CPU 切り替え)、各スレッドには独立したカウンターが必要で、スレッドのプライベート メモリは互いに影響を及ぼさず、この領域ではメモリ オーバーフロー例外は発生しません。

2. 仮想マシンスタック

これはスレッドプライベートであり、スレッドと同じ宣言サイクルを持ちます。仮想マシン スタックは、Java メソッド実行のためのメモリ モデルです。各メソッドの実行時にスタック フレームが作成されます。これは、メソッド実行中の基本的なデータ構造です。スタック フレームは、ローカル変数テーブル、オペランド スタック、動的リンク、メソッド終了などを格納するために使用されます。各メソッドの実行は、仮想マシン スタック フレームがスタックにプッシュされてからスタックからアンロードされるまでのプロセスに対応します。

これは仮想マシン内のローカル変数テーブルであり、物理層より上のプログラム データ モデルに対応するデータ構造です。

ローカル変数テーブルは、コンパイル時に既知のさまざまなデータ型を格納するプログラム実行データ モデルです。たとえば、次のようなものがあります。

Boolean、byte、char、short、int、float、long、double、オブジェクト参照型 (オブジェクト メモリ アドレス変数、ポインター、またはハンドル)。プログラムの実行中、スタック フレームのスペース サイズはローカル変数テーブルに従って割り当てられます。操作中、サイズは変更されません。例外タイプ: stackOverFlowError。スレッドは、仮想マシンで許可されている深さよりも大きいスタック深さを要求します。メモリ不足です。メモリ領域が不足しており、拡張できません。

3. ネイティブメソッドスタック

仮想マシン スタックと同様に、仮想マシン スタックは Java プログラムを提供し、ローカル メソッド スタックは仮想マシンの実行中のサービスをサポートします。具体的な実装は仮想マシンの製造元によって決定され、stackOverFlowError および OutOfMemory 例外もスローされます。

4.ヒープ

これは仮想マシン管理メモリの最大の部分であり、すべてのスレッドで共有され、オブジェクト インスタンス (オブジェクト、配列) を格納するために使用されます。物理的に不連続なメモリ空間です。 GC コレクターにより、世代別コレクションは、新しい世代の Eden、From SurVivor スペース、To SurVivor スペース、割り当てバッファー (割り当てスペース)、および複数のスレッド専用バッファーに分割され、古い世代になります。

5. 方法領域

ヒープと同様に、クラス情報、定数、静的変数、ジャストインタイムコンパイラ（OSGI の動的ロード）によってコンパイルされたコード、および仮想マシンによってロードされたその他のデータを格納するために使用されるスレッド共有メモリ領域です。理論的には Java 仮想マシンの一部であり、区別するために Non-Heap と呼ばれます。

この領域では、ガベージ コレクションを実行しないことを選択できます。この領域でのガベージ コレクションの目的は、主に定数プールをリサイクルし、その型のクラスをアンロードすることです。メモリ領域が不足している場合は、OutOfMemory 例外がスローされます。

ランタイム定数プール:

コンパイルされたクラスがロードされた後、メソッド領域の一部、クラス バージョン、フィールド、インターフェイス、メソッドなど、およびコンパイル中に生成されたさまざまなリテラルとシンボリック参照がこの領域に格納されます。 OutOfMemory 例外がスローされます。

6. 直接記憶

直接メモリは仮想メモリ領域に属しません。チャネルとバッファに基づいた IO メソッドです。ローカル関数を使用すると、オフヒープ メモリを直接割り当て、参照された外部メモリ アドレスをヒープに格納し、参照を通じて直接参照されたメモリの操作を完了できます。 1.4 以降で提供される NIO により、効率が大幅に向上し、ヒープ メモリとネイティブ メモリ間のコピー操作が回避されます。これは仮想マシンのメモリによって制御されず、OutOfMemory 例外がスローされます。

2: オブジェクトアクセスの内部実装プロセス

オブジェクト アクセスには、オブジェクト アドレスの変更、状態の変更、メモリ アドレスの移動、変数、インターフェイス、実装クラス、メソッド、親タイプなどが含まれます。

1. ハンドルモード（アクセス）

2. ポインタメソッド（アクセス）

長所と短所:

ハンドル アクセス メソッド: 参照には安定したアドレスが格納されます。オブジェクトが変更された場合、ハンドルインスタンスデータポインターのみが変更され、参照自体は変更する必要はありません。

ポインタアクセス方式: 利点: 速度が速く、ポインタ位置決め時間のオーバーヘッドを節約

3: メモリ領域制御パラメータと対応するオーバーフロー例外

開発プロセス中またはプログラムの実行中に、OutOfMemory 例外、GC 例外、または StackOverflowError 例外が発生するたびに、一連のパラメータをランダムに一致させて値を増やします。これは JVM のメモリ割り当てに関連していることはわかっていますが、具体的にどのように調整すればよいのか、また、対応する例外に対してどのパラメータを調整すればよいのかはわかりません。つまり、ほとんどの場合、どのパラメータが JVM メモリ割り当て領域に対応するかはわかりません。関連するパラメータを上げるだけで、期待される結果は機能するはずですが、実際に機能するかどうかはわかりません。以下では、JVM ヒープ、スタック、メソッド領域、およびその他のメモリ領域に対応するパラメータ、および各領域でスローされる可能性のある例外の種類と、例外が発生するシナリオの分析について説明します。

1. パラメータタイプ

1. ヒープスペースパラメータ

2. スタックスペースパラメータ

3. メソッド領域空間パラメータ

4. ネイティブダイレクトメモリパラメータ

2. 例外の種類

1. OutOfMemory例外

2. StackOverflowError例外

3. 補助パラメータの説明

1.-XX:+HeapDumpOnOutOfMemoryError はヒープメモリが異常な場合にスナップショット情報を出力します

2.-XX:+HeapDumpPath スナップショット出力パス

3.-Xmnはエデン領域のサイズを指定します -XX:SurvirorRationはサバイバー領域のサイズを調整します

4.-XX:PretenureSizeThresholdは、古い世代に入るためのしきい値を設定します。

4. パラメータの説明と対応するシーンの例外

1. ヒープメモリパラメータ

-Xms: 最小ヒープサイズ (新世代と旧世代の合計)

-Xmx: 最大ヒープサイズ（新世代と旧世代の合計）

最小値 = 最大値の場合、ヒープメモリは拡張できません。

例: -Xms80M -Xmx80M

通常、-Xmx と -Xms は GC の数を減らすために同じサイズに設定され、ヒープ メモリが不足すると OutOfMemoryError 例外がスローされます。

2. スタックメモリパラメータ

-Xss

例: -Xss128k

シングルスレッド環境では、スタック フレームが大きすぎるか、スタック容量が小さすぎるか、または参照深度が仮想マシンで許可されている深度を超えると、StackOverflowError がスローされます。各メソッドによってスタックにプッシュされるフレーム サイズが一貫していません。マルチスレッドでは、各スレッドに割り当てられたスタック フレームが大きすぎてメモリを拡張できない場合、OutOfMemoryError 例外がスローされます。スレッド スタック フレームが大きいほど、作成できるスレッドの数は少なくなります。

3. メソッド領域パラメータ

-XX:PermSize メソッド領域の最小メモリ値

-XX:MaxPermSize メソッド領域メモリ最大値

各スレッドで共有されるメモリ領域は、主にクラスのメタデータ、定数、静的変数、ジャストインタイムコンパイラによってコンパイルされたコード、その他のデータを格納するために使用されます。

例: -XX:PermSize=20M -XX:MaxPermSize=20M

例外タイプ OutOfMemoryError:

原因: 定数が多すぎる、プロキシ リフレクションを頻繁に使用しているなど。

4. ネイティブダイレクトメモリパラメータ

-XX:最大ダイレクトメモリサイズ

例: -XX:MaxDirectMemorySize=10M

不十分な場合はOutOfMemory例外がスローされます

4: ガベージコレクションアルゴリズム

古典的なガベージコレクションアルゴリズムは以下のとおりです。

1. マークスイープ

リサイクル前の状態:

リサイクル後の状態:

長所と短所:

アルゴリズムの実行は、マーキングとクリアの 2 つの段階に分かれています。すべてのリサイクルアルゴリズムは基本的に

マークリサイクルアルゴリズムに基づく高度な最適化

デメリット: 効率の問題、メモリ空間の断片化 (不連続な空間)

2. コピーアルゴリズム

リサイクル前の状態:

エデンメモリスペース8

サバイバー1 宇宙（宇宙から）1

サバイバー2 スペース（スペースへ）1

エデンの記憶空間とサバイバー空間 8:1

リサイクル後の状態:

サバイバー1 宇宙（宇宙から）1

エデンの記憶空間とサバイバー空間 8:1

長所と短所:

マークスイープアルゴリズムと比較すると、リサイクルによって発生するメモリの断片化の問題を回避します。

デメリット: ローカル メモリ領域を消費しますが、無駄になる領域は比較的小さくなります。デフォルトの 8:1 比率 1 は無駄です。

コピーには一定の効率性とスペースコストも伴う

3. マークコンパクト

リサイクル前の状態:

リサイクル後の状態:

長所と短所:

スペースの無駄やメモリの断片化の問題を回避します。

デメリット: ソート時にコピーすると効率が低下します。

5: ガベージコレクター

1. 7種類のガベージコレクター

(1) シリアル（シリアルGC） -XX:+UseSerialGC

(2) ParNew (並列GC) -XX:+UseParNewGC

（３）並列スカベンジ（並列GC）

(4) シリアルオールド (MSC) (シリアルGC) -XX:+UseSerialGC

(5) CMS (同時GC) -XX:+UseConcMarkSweepGC

(6) パラレルオールド（並列GC）-XX:+UseParallelOldGC

（7）G1（公式商用利用はJDK1.7update14のみ利用可能）

2.1～3は若い世代のガベージコレクションに使用されます。若い世代のガベージコレクションはマイナーGCと呼ばれます。

3.4～6は旧世代のガベージコレクションに使用されます（もちろんメソッドエリアコレクションにも使用できます）。旧世代のガベージコレクションはフルGCと呼ばれます。

G1が「世代別ガベージコレクション」を独自に完了

注: 並列性と同時実行性

並列処理: 複数のガベージコレクションスレッドが同時に動作する

並行性: ガベージコレクションスレッドはユーザースレッドと連携して動作します

4つ。よく使われる5つの組み合わせ

シリアル/シリアル旧

ParNew/Serial Old: 上記と比較すると、若い世代よりもマルチスレッドのガベージコレクションが多くなっています。

ParNew/CMS: 現時点では比較的効率的な組み合わせ

Parallel Scavenge/Parallel Old: 自動的に管理される組み合わせ

G1: 最も高度なコレクターですが、JDK1.7update14以上が必要です

5. シリアル/シリアルオールド

若い世代のシリアルコレクターは、単一のGCスレッドを使用して「コピー」アルゴリズム（スキャンとコピーを含む）を実装します。

旧世代のシリアルオールドコレクターは、単一のGCスレッドを使用して「マークスイープ」アルゴリズムを実装します。

Serial と Serial Old は両方ともすべてのユーザー スレッド (STW) を一時停止します。

例:

STW (Stop The World): コードをコンパイルするときに、各メソッドにセーフポイント (メソッド内のループが終了するポイント、メソッドの実行が終了するポイント) が挿入されます。アプリケーションを一時停止する場合は、すべてのユーザー スレッドがセーフポイントに入るまで待機し、すべてのスレッドを一時停止してから、ガベージ コレクションを実行する必要があります。

適用場面:

CPU コアが 2 個未満で物理メモリが 2 GB 未満のマシン (簡単に言えば、CPU が 1 個で、新世代スペースが小さく、STW 時間の要件が低いマシン)

-XX:UseSerialGC: このGCの組み合わせの使用を強制する

-XX:PrintGCApplicationStoppedTime: STW時間を表示

6.ParNew/Serial Old:

ParNew は、コピー アルゴリズムを実装するために複数の GC スレッドを使用する点を除いて Serial と同じです。ただし、この組み合わせの Serial Old は単一の GC スレッドであるため、この組み合わせはかなり扱いにくいものになります。シングル CPU の状況では Serial/Serial Old ほど高速ではありません (ParNew マルチスレッドを切り替える必要があるため)。また、マルチ CPU の状況では次の 3 つの組み合わせほど高速ではありません (Serial Old は単一の GC スレッドであるため)。そのため、あまり使用されません。

-XX:ParallelGCThreads: ParNew GC スレッドの数を指定します。デフォルトではCPUコアの数と同じです。このパラメータは、CMS GC と組み合わせて使用​​することもできます。

7. パラレルスカベンジ/パラレルオールド:

特徴：

新しい世代の Parallel Scavenge コレクターは、複数の GC スレッドを使用して「コピー」アルゴリズム (スキャンとコピーを含む) を実装します。旧世代の Parallel Old コレクターは、複数の GC スレッドを使用して「マーク アンド スイープ」アルゴリズムを実装します。 ParallelScavenge と Parallel Old はどちらもすべてのユーザー スレッド (つまり、STW) を一時停止します。

例:

スループット: CPU コード実行時間 / (CPU コード実行時間 + GC 時間) CMS は STW の短縮に重点を置いています (この時間が短いほどユーザー エクスペリエンスが向上するため、主に多くのインタラクティブ タスクを処理するために使用されます) Parallel Scavenge/Parallel Old はスループットに重点を置いています (スループットが大きいほど CPU 使用率が高くなるため、主に多くの CPU コンピューティング タスクと少数のユーザー インタラクティブ タスクを処理するために使用されます)

パラメータ設定:

-XX:+UseParallelOldGC: このGCの組み合わせを使用する

-XX:GCTimeRatio: スループット サイズを直接設定します。 19 に設定されている場合、許容される最大 GC 時間は合計時間の 1/(1+19) になります。デフォルト値は99、つまり1/(1+99)です。

-XX:MaxGCPauseMillis: GC の最大一時停止時間。パラメータが小さいほど良いです。

-XX:+UseAdaptiveSizePolicy: このパラメータをオンにすると、-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold などのパラメータは機能しなくなります。仮想マシンは監視情報を自動的に収集し、これらのパラメータを動的に調整して、最も適切な一時停止時間または最大スループットを提供します (GC 適応調整戦略)。設定する必要があるのは、-Xmx、-XX:+UseParallelOldGC、または-XX:GCTimeRatioです（もちろん、-Xmsも-Xmxと同じに指定できます）。

知らせ：

-XX:GCTimeRatioと-XX:MaxGCPauseMillisのいずれかを設定するだけです

-XX:+UseAdaptiveSizePolicy を有効にしなくても、-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold などのパラメータは構成できます。樹脂サーバーを例に挙げる

<jvm-arg>-Xms2048m</jvm-arg> <jvm-arg>-Xmx2048m</jvm-arg> <jvm-arg>-Xmn512m</jvm-arg> <jvm-arg>-Xss1m</jvm-arg> <jvm-arg>-XX:PermSize=256M</jvm-arg> <jvm-arg>-XX:MaxPermSize=256M</jvm-arg> <jvm-arg>-XX:SurvivorRatio=8</jvm-arg> <jvm-arg>-XX:MaxTenuringThreshold=15</jvm-arg> <jvm-arg>-XX:+UseParallelOldGC</jvm-arg> <jvm-arg>-XX:GCTimeRatio=19</jvm-arg> <jvm-arg>-XX:+PrintGCDetails</jvm-arg> <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg> コードを表示

適用場面:

CPU コンピューティング タスクは多数ありますが、ユーザー インタラクション タスクはほとんどありません。 GC パラメータにあまり注意を払いたくないので、仮想マシン自体にチューニング作業を行わせたい場合。

8. チューニング方法

8.1 新世代で予約された新しいオブジェクト

フルGC（旧世代）のコストはマイナーGC（新世代と旧世代）のコストよりもはるかに大きいため、アプリケーションには適切な新世代スペースが割り当てられ、オブジェクトは可能な限り新世代に割り当てられ、フルGCの頻度が削減されます。

8.2 大きなオブジェクトが古い世代に入る

大きなオブジェクトを古い世代に直接割り当てて、新しい世代のオブジェクトの構造の整合性を維持し、GC 効率を向上させます。古い世代に入るしきい値を設定するには、-XX:PretenureSizeThreshold を使用します。

8.3 安定ヒープサイズと変動ヒープサイズ

-Xms と -Xmx を同じサイズにすることで、安定したサイズがガベージ コレクションに適しています。

8.4 スループットの優先度

システムがガベージコレクションを実行するのにかかる合計時間を最小限に抑えるために、並列ガベージコレクタが使用されます。

-XX:+UseParallelGC または -XX:+UseParallelOldGC を使用する

8.5 一時停止を減らす

CMSコレクターを使用してfullGCの数を減らす

9. gc情報の取得方法

9.1 -verbose:gc または -XX:+PrintGC を使用して gc 情報を取得する

9.2 -XX:+PrintGCDetails より詳細なGC情報を取得する

9.3 -XX:+PrintGCTimeStamps GCの頻度と間隔を取得する

9.4 -XX:+PrintHeapAtGC ヒープ使用量を取得する

9.5 -Xloggc:D:\gc.log はログを保存するパスを指定します

10. JVM チューニングの実践 - Tomcat の起動の高速化

tomcatのbin/catalina.batファイルの先頭に適切な設定を追加します。

6. 監視ツール

監視ツール: 一般的に、問題の特定とパフォーマンスの調整に使用されます。

(a) jps

Jps は、Unix システムの命名規則に従って命名されます。その機能は ps の機能に似ています。実行中の仮想マシン プロセスを一覧表示し、仮想マシン実行のメイン クラスとこれらのプロセスの一意の ID (LVMID、ローカル マシンの PID と同じ) を表示できます。使い方は以下のとおりです。

Jps [オプション] [ホストID]

jps -qはLVMIDのみを出力します

jps -mはJVMの起動時にメインクラスに渡されるメソッドを出力します。

jps -lはメインクラスのフルネームを出力し、それがJarの場合はjarのパスを出力します。

jps -vはJVMの起動パラメータを出力します。

（ii）ジェイスタット

jstat は主に、クラスのロード、メモリ、ガベージ コレクション、JIT コンパイラなど、仮想マシンのさまざまな動作ステータス情報を監視するために使用されます。GUI のないサーバーでは、このツールが推奨される監視ツールです。使い方は以下のとおりです。

jstat [オプション vmid [間隔 [s|ms] [回数] ] ]

jstatはコンテンツを更新するスレッドの数を監視します

jstat –gc 20445 1 20 : エデン、2つのサバイバー領域、古い領域、永続領域の容量、使用領域、GC時間の合計などを含むJavaヒープを監視します。

jstat –gcutil 20445 1 20: -gcと同じものを監視しますが、出力は使用済みスペースと総スペースのパーセンテージに焦点を当てています。

jstat –class 20445 1 20: ロードおよびアンロードされたクラスの数、クラスのロードに消費された合計スペースと時間などを監視します。

.......-gccapcity......: 監視内容は-gcと同じですが、出力はJava領域で使用される最大および最小スペースに焦点を当てています。

.......-gccause........: -gcutil と同じ出力情報に加え、最後の GC の原因も出力します。

.......-gcnew..........: 新世代のGCステータスを監視する

.......-gcnewcapacity..: -gcnew 監視情報と同じですが、出力は使用されている最大および最小のスペースに焦点を当てています。

.......-gcold..........: 古い世代のGCステータスを監視する

.......-gcoldcapacity..: -gcold 監視情報と同様、出力は使用されている最大および最小のスペースに焦点を当てます。

.......-gcpermcapacity.: 永久バンドが使用する最大および最小のスペースを出力します

.......-compiler.......: JITコンパイラによってコンパイルされたメソッドと時間のかかる情報を出力します

.......-printcompilation: JITコンパイルされた出力メソッド

(III) ジンフォ

jinfo の機能は、仮想マシンのさまざまなパラメータ情報をリアルタイムで表示することです。 jps -v は仮想マシンの起動時に明示的に指定されたパラメータ情報を表示できますが、デフォルトのパラメータ情報を知りたい場合はどうすればよいでしょうか。対応する情報を照会することに加えて、jinfo が非常に重要になります。 jinfo の使い方は次のとおりです。

Jinfo [オプション] pid

(IV) jmap

map はヒープ スナップショット (ヒープダンプ) を生成するために使用されます。もちろん、対応するダンプ情報を取得する方法はたくさんあります。たとえば、JVM の起動時に起動パラメータ –XX:HeapDumpOnOutOfMemoryError を追加すると、メモリ オーバーフロー エラーが発生したときに JVM が自動的にダンプ ファイルを生成できるようになります。 -XX:HeapDumpOnCtrlBreak パラメータを使用して、Ctrl + Break キーで実行時にダンプ ファイルを生成することもできます。もちろん、kill -3 pid を使用して JVM にダンプ ファイルを生成するよう強制することもできます。 Jmap の役割は、ダンプ ファイルを取得するだけでなく、スペース使用率、ガベージ コレクターなど、ファイナライズ実行キュー、Java ヒープ、永続バンドに関する詳細情報を照会することです。その動作形式は次のとおりです。

Jmap [オプション] vmip

スタック情報の監視は主に問題の原因を特定し、スタックのスナップショットを生成するために使用されます。

.......-dump......: 対応するダンプ情報を生成します。使用方法は -dump:[live,]format=b,file={fileName} です。

.......-finalizerinfo......: F-Queue で待機している Finalizer メソッドのオブジェクトを表示します (Linux でのみ有効)

.......-heap......: ヒープ詳細情報、ガベージコレクター情報、パラメータ設定、生成詳細などを表示します。

.......-histo......: スタック内のオブジェクトの統計情報（クラス、インスタンス数、総容量など）を表示します。

.......-permstat......: ClassLoderを統計基準として、パーマネントバンドのメモリステータスを表示します。

.......-F......: このオプションは、仮想マシンが-dumpに応答しない場合にダンプスナップショットを強制的に生成するために使用できます。

例: jmap -dump:format=b,file=yhj.dump 20445

(V) jstack

Jstack は、現時点での JVM のスレッド スナップショット (スレッドダンプ ファイルとも呼ばれます) に使用されます。これは、JVM の各スレッドによって現在実行されているスタック情報のコレクションです。スレッド スナップショットを生成する主な目的は、スレッドのデッドロック、無限ループ、外部要求の持続時間が長すぎるために発生するスレッドの一時停止など、スレッドが長時間一時停止する理由を特定することです。 jstack を使用すると、どのプロセスがバックグラウンドで何を実行しているかを知ることができますか?どのようなリソースを待っていますか?動作形式は以下のとおりです。

Jstack [オプション] vmid

-F 通常の出力要求が応答しない場合にスレッドスタックの出力を強制する

-l スタック情報に加えてロックに関する追加情報を表示します

-m はネイティブメソッドのスタック情報を表示します

(6) jconsole

JDK bin ディレクトリで、メモリ、スレッド、スタックなどを監視します。

(VII) ジェイプロファイル

jconsole に似ていますが、メモリ、スレッド、パッケージ、カップ クラス、スタックなど、jconsole よりも包括的な監視情報を提供します。