この記事では、スレッド共有からネイティブメソッドスタック、Javaヒープまで、JVMメモリモデルについて詳しく説明します。

序文

JVM メモリモデルを正式に学習する前に、次の点に注意してください。

JVM メモリモデルと JAVA メモリモデルは同じ概念ではありません。 JVM メモリモデルは、ランタイムデータ領域の構造の観点から説明される概念です。一方、JAVA メモリモデルは、メインメモリとスレッドプライベートメモリの観点から説明されています。次の 2 つの画像からわかるように:

[[285399]]

JAVA メモリモデル

JVM メモリモデル

Java 仮想マシンは、クラスローダー、サブシステム、ランタイムデータ領域、実行エンジンという 3 つの主要モジュールで構成されています。この記事では、2 番目に大きなモジュールであるランタイムデータ領域 (JVM メモリモデル) について説明します。
実際、仮想マシンのこれらのモジュールは独立しているのではなく、相互に接続されています。 Java ファイルはクラスファイルにコンパイルされ、クラスローディングサブシステムを介してロードされ、情報は JVM によって管理されるメモリに流れ (一部の操作はローカルメモリと対話します)、その後ガベージコレクションなどに送られます。これらはすべて一連の操作です。

概要

ランタイムデータ領域は、いくつかの主要なモジュールに分かれています (上図を参照)。

スレッド共有領域:

JAVA ヒープ
方法領域

スレッドプライベートエリア:

JAVAスタック
ネイティブメソッドスタック
プログラムカウンタ

この記事では、各地域を以下の視点から分析します。

関数
保存されたコンテンツ
メモリオーバーフローまたはメモリリークが発生していますか?
ガベージコレクションを実行するかどうか
対応するガベージコレクションアルゴリズム
ガベージコレクションプロセス
パフォーマンスチューニング

スレッドプライベートエリア

プログラムカウンタ

プログラムカウンターはメモリ空間の小さな部分であり、現在のスレッドによって実行されたバイトコードの行番号インジケーターとして考えることができます。バイトコードインタープリターが動作しているとき、このカウンターの値を使用して、次に実行するバイトコード命令を選択します。分岐、ループ、ジャンプ、例外処理、スレッド回復はすべてこの領域に依存します。

簡単に言えば、この領域にはメソッド領域内のメソッドバイトコードへのポインタが格納され、次の命令、つまり実行される命令コードのアドレスを格納するために使用されます。

スレッドが Java メソッドを実行している場合、このカウンターは実行中の仮想マシンバイトコード命令のアドレスを記録します。ネイティブメソッドが実行されている場合、カウンター値は空 (未定義) になります。

命令コード行が実行されると、JVM 実行エンジンはプログラムカウンターの値を更新します。

Java 仮想マシンのマルチスレッドは、スレッドを順番に切り替えてプロセッサ実行時間を割り当てることによって実装されるため、特定の瞬間にプロセッサ (マルチコアプロセッサの場合はコア) は 1 つのスレッド内の命令のみを実行します。そのため、スレッド切り替え後に正しい実行位置に戻すためには、各スレッドが独立したプログラムカウンターを持つ必要があります。スレッド間のカウンターは互いに影響を及ぼさず、独立して保存されます。このタイプのメモリ領域を「スレッドプライベート」メモリと呼びます。 (メソッドが呼び出され、そのメソッド内で別のメソッドが呼び出されます。これは、スタックの「先入れ先出し、後入れ後出し」モデルを正式に満たします)。

メモリ不足エラー: なし

仮想マシンスタック

これは Java メソッド実行のメモリモデルを記述したもので、そのライフサイクルはスレッドのライフサイクルと同じです。

各メソッドは実行時にスタックフレームを作成します。各スタックフレームには、ローカル変数テーブル、オペランドスタック、動的リンク、メソッド終了などが含まれます。メソッドが呼び出され、そのメソッド内で別のメソッドが呼び出されます。これにより、スタックの「先入れ先出し、後入れ後出し」モデルが正式に満たされます。つまり、メソッドの呼び出しから実行までのプロセスは、スタックフレームをプッシュしてから仮想マシンスタックにポップするまでのプロセスに対応します。

上記は、深く理解するのが難しい、非常に機械的な概念のほんの一部です。以下では、例を使用して仮想マシンスタックのストレージコンテンツを分析します。

まず簡単なプログラムを作成します。

パッケージ com.sunwin.robotcloud.test;
 /**
 * 2019-11-01に追梦1819によって作成されました。
 */
パブリッククラスCalculateMain{
公共  int計算(){
整数a = 3;
整数b=4;
整数c = a+b;
 cを返します。
 }
公共 静的void main(String[] args) {
 CalculateMain main = 新しい CalculateMain();
 int d = main.calculate();
 システム.out.println (d) ;
 }

上記のプログラムでは、スレッドが開始されると、仮想マシンはメインスレッド main に大きなメモリ空間を割り当て、次に main メソッドにスタックフレームを割り当てて、メソッドのローカル変数を格納します。

calculate() メソッドが実行されると、対応するメソッドのローカル変数を格納するために calculate() スタックフレームが割り当てられます。

メソッドはスタックフレームという単一のメモリ領域を割り当てることに注意することが重要です。

Java は高級言語であり、コードを通じてその実行プロセスを直接確認することは困難です。基礎となるバイトコードを解凍し、実行された命令コードを抽出することで、基礎となる実行プロセスを分析します。

CalculateMain.class ファイルディレクトリに入り、次のコマンドを実行します。

コマンドコードを CalculateMain.txt ファイルに直接出力します。

編集元  「CalculateMain.java」  
パブリッククラス com.sunwin.robotcloud.test.CalculateMain {
パブリックcom.sunwin.robotcloud.test.CalculateMain();
 コード：
 0: ロード_0
 1:invokespecial #1 // メソッド java/lang/Object。 「<init>」 :()V
 4:戻る  
 
公共 整数計算();
 コード：
 0: アイコンst_3
 1: istore_1
 2: アイコンst_4
 3: istore_2
 4: ロード1
 5: ロード2
 6: 追加
 7: istore_3
 8: ロード3
 9: 戻る
 
公共 静的void main(java.lang.String[]);
 コード：
 0: 新しい #2 // クラス com/sunwin/robotcloud/test/CalculateMain
 3: 重複
 4: 呼び出しスペシャル #3 // メソッド"<init>" :()V
 7: アストア1
 8: ロード1
 9:invokevirtual #4 // メソッド calculate:()I
 12: istore_2
 13: getstatic #5 // フィールド java/lang/System.出力:Ljava/io/PrintStream;
 16: ロード2
 17:invokevirtual #6 // メソッド java/io/PrintStream.println:(I)V
 20:戻る 
 }

まず、calculate() メソッドを見てみましょう。上記の手順に従って、JVM の取扱説明書を照会し、上記のプログラムの実行フローを取得します。

0. int 型定数 3 を (オペランド) スタックにプッシュします。

1. int 型の値 3 をローカル変数 1 (1 は配列の添え字) に格納します。つまり、ローカル変数テーブル内の a にメモリの一部を割り当てます (3 を格納するため)。

2. int型定数4を（オペランド）スタックにプッシュします。

3. int型の値4をローカル変数2に格納します。

4. ローカル変数 1 から int 型の値をロードします。つまり、ローカル変数テーブルの値 3 を取り出してオペランドスタックにロードします。

5. ローカル変数 2 から int 型の値を読み込みます。

6. 2つの値を追加します。

7. (オペランドスタックに数値を格納しますか?) int 値 7 をローカル変数 3 に格納します。

8. ローカル変数 3 から int 型の値を読み込みます。

9. 計算された値を返します。

上記はメソッド実行時のメモリ内のローカル変数のフロー処理です。要約すると、次のとおりです。

オペランドスタックは、操作中のデータの一時的な転送ステーションに相当します。

ローカル変数テーブル: ローカル変数の保存スペース。ワード長を単位とし、0からカウントされる配列です。int、float、reference、retrueAddress型の値は1つの項目のみを占めます。 byte、short、char 型の値は、配列に格納される前に int 値に変換されます。 long 型と double 型の値は、連続する 2 つの項目を占めます。インデックスは最初の値を指します。

ただし、仮想マシンは byte、short、char を直接サポートしますが、ローカル変数テーブルとオペランドスタックでは int 値に変換され、ヒープとメソッド領域では元の型のままであることに注意してください。

オペランドスタック: データ操作のための一時スペース。ローカル変数テーブルに似ています。唯一の違いは、インデックスではなく、プッシュとポップによってアクセスされることです。

動的リンク: 実行時に動的に生成されるメソッドの JVM 命令コードのメモリアドレスを格納します。

オブジェクトにはオブジェクトヘッダーがあり、その中で型ポインターはメソッド領域内のクラスメタ情報を指します。

メソッド終了: メソッドを終了して次のメソッドに入るプログラムカウンターの値を格納します。

JAVAスタック構造

例外: スレッドによって要求されたスタックの深さが仮想マシンで許可されている深さより大きい場合、StackOverflowError 例外がスローされます。仮想マシンスタックを動的に拡張できる場合 (現在の Java 仮想マシンのほとんどは動的に拡張できますが、Java 仮想マシン仕様では固定長の仮想マシンスタックも許可されています)、拡張中に十分なメモリを要求できない場合は OutOfMemoryError 例外がスローされます。

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

ネイティブメソッドスタックは、実際には Java 仮想マシンスタックと非常によく似ています。唯一の違いは、Java 仮想マシンスタックは Java メソッドを提供し、ネイティブメソッドスタックはネイティブメソッドを提供することです。仮想マシン仕様では、ネイティブメソッドスタック内のメソッドで使用される言語、使用法、データ構造に関する必須規定がないため、特定の仮想マシンが自由に実装できます。

StackOverflowError および OutOfMemoryError 例外もスローされる可能性があります。

スレッド共有領域

方法領域

この領域には、仮想マシンによってロードされたクラス情報 (フィールドメソッドのバイトコード、一部のメソッドのコンストラクタ)、定数、静的変数、コンパイルされたコード情報など、およびクラスのすべてのフィールドとメソッドのバイトコードが格納されます。コンストラクターなどのいくつかの特殊なメソッドだけでなく、インターフェースのコードもここで定義されます。つまり、定義されたすべてのメソッドの情報がこの領域に保存されます。静的変数 + 定数 + クラス情報 (コンストラクター/インターフェース定義) + ランタイム定数プールがすべて存在します。

不連続、固定サイズ、拡張可能、またはガベージコレクターがない場合もあります。この領域ではガベージコレクションが存在します。ただし、頻度は低くなります。

メソッド領域は定義と概念であり、永続的な世代またはメタスペースは実装メカニズムです。

OutOfMemoryError: はい

ランタイム定数プール

クラスファイルには、クラスバージョン、フィールド、メソッド、インターフェイス、およびその他の説明情報に加えて、コンパイル中に生成されるさまざまなリテラルとシンボリック参照を格納するために使用される定数プール (定数プールテーブル) も含まれています。このコンテンツは、クラスがロードされた後にメソッド領域内のランタイム定数プールに保存されます。

OutOfMemoryError: はい

JAVA ヒープ

ヒープは、Java 仮想マシンによって管理されるメモリの最大の領域であり、その唯一の機能はオブジェクトインスタンスを格納することです。ほぼすべてのオブジェクト (定数プールを含む) はヒープ上にメモリを割り当てます。

インスタンスの割り当てを完了するためのメモリがヒープ内に存在せず、ヒープをそれ以上拡張できない場合は、OutOfMemoryError 例外がスローされます。

ガベージコレクターの主な管理領域。

ガベージコレクションの観点から、この領域は新しい世代と古い世代に分けられます。新世代はエデン空間とサバイバー空間に分かれています。サバイバーペースは、サバイバー From スペースとサバイバー To スペースに分かれています。次の図に示すように:

上記のエリアのサイズ分布は次のとおりです。

若い世代: ヒープ全体の1/3

古い世代: ヒープの 2/3

エデン地区：新世代の8/10

ゾーンからの生存者: 新世代の1/10

生存者ゾーン: 新世代の1/10

メモリ割り当ての観点から言えば、複数のスレッド専用の割り当てバッファを分割することができます。

ヒープスペースの場合、本質はオブジェクトインスタンスを格納することです。ただし、パーティショニングは、オブジェクトインスタンスの割り当てと管理を改善するためだけに行われます。ヒープ空間内のオブジェクトインスタンスの管理とリサイクルについては、次の章で説明します。

同時に、物理的には連続していないかもしれませんが、論理的には連続している必要があります。

JVM メモリモデルの全体的な構造は次のとおりです。

オブジェクトのリサイクルプロセス

以下の写真はインターネットから取得したものです。

すべてのクラスはエデンエリアに新しく作成されます。 Eden 領域がいっぱいになると、マイナー GC がトリガーされ、他のオブジェクトから参照されなくなったオブジェクトは破棄され、残りのオブジェクトは From Survivor 領域に移動されます。マイナー GC がトリガーされるたびに、オブジェクトの世代年齢が +1 されます (世代年齢はオブジェクトヘッダーに保存されます)。 From Survivor 領域がいっぱいになると、From Survivor 領域でマイナー GC がトリガーされ、未収集オブジェクトの世代年齢が 1 ずつ増加し続け、To Survivor 領域に移動されます。このとき、エデン内の未収集オブジェクトも「To Survivor」エリアに移動されます。「To Survivor」エリアがいっぱいになると、「From Survivor」エリアに移動されます。

オブジェクトの世代年齢が 15 に達すると、オブジェクトは古い世代に入ります (静的変数 (オブジェクト型)、データベース接続プールなど)。古い世代もいっぱいの場合は、この時点で古い領域のメモリをクリーンアップするためにメジャー GC (フル GC) が発生します。旧領域でFull GCを実行し、オブジェクトを保存できないことが判明した場合、OOM例外OutOfMemoryErrorが生成されます。

予防

異なるバージョンでは、ランタイムデータ領域に次のようなわずかな違いがあります。メタデータ領域: メタデータ領域は、永続世代 (jdk1.8 より前) を置き換えます。本質的には永久世代と同様です。どちらも、JVM 仕様のメソッド領域の実装です。違いは、メタデータ領域が仮想マシン内になく、ローカルの物理メモリを使用することです。永続的な世代は仮想マシン内にあります。永続世代は、論理構造上はヒープに属しますが、物理的には属しません。ヒープサイズ = 新しい世代 + 古い世代。メタデータ領域でも OutOfMemory 例外が発生する可能性があります。 jdk1.6 以前: 永続的な世代があり、定数プールはメソッド領域にあります。 jdk1.7: 永続世代がありますが、徐々に「永続世代に移行」し、定数プールはヒープ内にあります。 jdk1.8 以降: 永続的な世代はなく、定数プールはメタスペースにあります (仮想マシンによって管理されるメモリではなく、コンピューターの直接メモリを使用します)。
JDK 1.8 で永続世代がメタデータ領域に置き換えられたのはなぜですか?公式の説明: 永続的な世代を削除するのは、JRockit には永続的な世代がなく、構成する必要がないため、HotSpot JVM と JRockit VM を統合するための取り組みです。（簡単に言うと、二人が競争して、勝った方が聴く権利を得るのです。）
メタデータ領域の動的な拡張。デフォルトの –XX:MetaspaceSize 値は、最高水準点の 21 MB です。一度触れると、Full GC がトリガーされ、役に立たないクラスがアンロードされ (クラスに対応するクラスローダーが動作しなくなります)、最高水準点がリセットされます。新しい最高水準値は、GC 後に解放されたメタスペースによって異なります。解放されるスペースが少ないと、最高水準点が上昇します。解放されたスペースが多すぎると、最高水準点が下がります。

<<: テクノロジーの選択: Docker コンテナエンジン

>>: ブロックチェーン分散ストレージの利点は何ですか?知っておくべき4つの大きなメリット