JVMランタイムデータ領域、メソッド領域、永続的世代、メタスペースについては本書では明確に説明されていない

この記事はWeChatの公開アカウント「Flying Veal」から転載したもので、著者はVealです。記事を転載する場合は飛天牛肉公式アカウントまでご連絡ください。

データベースシリーズの執筆はほぼ終わりました。冬休み中に JVM についての読み終えて、学校が始まったらフレームワークについて読み、秋の採用に備えて一般的な知識を覚えるつもりです。さっそく、JVM の最初の知識ポイントは、Java プログラムの実行時のデータ領域の分割に当てられる必要があります。

いつも通り、朗読バージョンは記事の最後にあります。クリックすると原文を読むことができ、私がまとめた大手企業の面接質問に直接移動します

JVM ランタイムデータ領域の概要

Java プログラムの実行中 (ランタイムと呼ばれる)、JVM は管理するメモリを複数の異なるデータ領域に分割します。これらのエリアには独自の用途があり、作成および破壊のタイミングも異なります。一部の領域は仮想マシンプロセスが開始されている限り存在しますが、一部の領域はユーザースレッドの開始と終了に応じて作成および破棄されます。

Java 仮想マシン仕様によれば、Java 仮想マシンによって管理されるメモリには、次の図に示すように、次のランタイムデータ領域が含まれます。

図からわかるように、スレッド間で共有される領域はメソッド領域とヒープであり、スレッド間で分離される領域（スレッドプライベート）は仮想マシンスタック、ローカルメソッドスタック、プログラムカウンタです。

スレッド共有とスレッドプライベートの意味を簡単に説明します。

いわゆるスレッドプライバシーとは、簡単に言えば、各スレッドが独自のスペースを作成し、各スレッド間のプライベートスペースは互いに影響を及ぼさず、独立して保存されることを意味します。たとえば、プログラムカウンターはスレッド専用です。各スレッドには独自のプログラムカウンターがあり、互いに干渉しません。
スレッド共有については特に言うことはありません。簡単に言えば、誰でもアクセスでき、すべてのスレッドが保存されたデータにアクセスできるパブリックな場所として理解できます。

これらのデータ領域を個別に説明しましょう。

スレッドプライベート: プログラムカウンタレジスタ

プログラムカウンターは、現在のスレッドによって実行されたバイトコードの行番号インジケーターと考えることができる小さなメモリです。バイトコードインタープリタが動作する場合、このカウンタの値を変更して、次に実行するバイトコード命令を選択します。分岐、ループ、ジャンプ、例外処理、スレッド回復などの基本機能はすべて、このカウンターに依存して完了します。

Java 仮想マシンのマルチスレッドは、スレッドを順番に切り替えてプロセッサ実行時間を割り当てることによって実装されるため、特定の瞬間にプロセッサ (マルチコアプロセッサの場合はコア) は 1 つのスレッド内の命令のみを実行します。

そのため、スレッド切り替え後に正しい実行位置に戻すためには、各スレッドが独立したプログラムカウンターを持つ必要があり、スレッド間のカウンターは互いに影響を及ぼしません。

では、プログラムカウンターには何が保存されるのでしょうか?

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

注記！このメモリ領域は、Java 仮想マシン仕様で OutOfMemoryError 状況が指定されていない唯一の領域です。この質問は比較的よく聞かれる面接の質問です。

スレッドプライベート: Java 仮想マシンスタック

仮想マシンスタックは、実際にはスタックフレームが 1 つずつ構成されています。スタックフレームは、Java メソッド実行のメモリモデルを記述します。つまり、各メソッドは実行時にスタックフレームを同期的に作成し、ローカル変数テーブル、オペランドスタック、動的リンク、メソッドの戻りアドレスなどの情報を格納するために使用されます。

各メソッドが呼び出されてから実行されるまでのプロセスは、スタックフレームが仮想マシンスタックにプッシュされてからスタックからポップされるまでのプロセスに対応します。

このうち、ローカル変数テーブルには次の 3 種類のデータが格納されます。

コンパイル時に認識される Java 仮想マシンのさまざまな基本データ型: boolean、byte、char、short、int、float、long、double
オブジェクト参照、参照型: オブジェクト自体と同等ではありません。これは、オブジェクトの開始アドレスを指す参照ポインターである場合もあれば、オブジェクトまたはこのオブジェクトに関連する他の場所を表すハンドルを指す場合もあります。（参照型に関しては、ハンドルを使ってアクセスする方法と、直接ポインタを使ってアクセスする方法の2つの方法があります。これについては、以降の記事で詳しく説明します）
returnAddress型: バイトコード命令のアドレスを指す

ローカル変数テーブル内のこれらのデータ型の記憶領域は、ローカル変数スロットによって表されます。つまり、ローカル変数テーブルの基本記憶単位はスロットです。 JVM は各スロットにアクセスインデックスを割り当て、このインデックスを通じてローカル変数テーブルに格納された値に正常にアクセスできます。

このうち、64 ビットの long および double データ型は 2 つのスロットを占有し、残りのデータ型は 32 ビットで 1 つのスロットのみを占有します。

Java 仮想マシン仕様では、仮想マシンスタックメモリ領域に対して 2 種類の例外が指定されています。

スレッドが要求したスタックの深さが仮想マシンで許可されている深さより大きい場合、StackOverflowError例外がスローされます（スタックオーバーフロー）
使用されている JVM が仮想マシンスタック容量の動的な拡張をサポートしている場合、スタック拡張中にメモリ不足が要求されると、OutOfMemoryError 例外がスローされます。

スレッドプライベート: ネイティブメソッドスタック

ローカルメソッドスタックは、基本的に前述の仮想マシンスタックと同じ機能を持ちます。唯一の違いは、ローカルメソッドスタックは仮想マシンが使用するネイティブメソッドを提供するのに対し、仮想マシンスタックは仮想マシンが Java メソッド (つまり、バイトコード) を実行するために提供されることです。

ここではネイティブ方式の概念について説明します。実際、この概念は Java だけでなく、多くの言語にも存在します。

「ネイティブメソッドとは、Java 以外のコードによって実装が提供される Java メソッドです。」

つまり、ネイティブメソッドは実際にはインターフェイスですが、その特定の実装は C や C++ などの Java 以外の言語で外部的に記述されます。 Java は JNI を介してネイティブメソッドを呼び出し、ネイティブメソッドはライブラリファイル (WINDOWS プラットフォームでは DLL ファイル、UNIX マシンでは SO ファイル) の形式で保存されます。

したがって、同じネイティブメソッドが異なる仮想マシンによって呼び出された場合、結果と実行効率が異なる場合があります。これは、仮想マシンによって、Object クラスの hashCode メソッドなどの特定のネイティブメソッドの独自の実装があるためです。

では、なぜネイティブメソッドが必要なのでしょうか?

主な理由は、Java は使いやすいものの、一部のレベルのタスクは Java で実装するのが容易ではない、またはプログラム効率に対する要件が比較的高い場合、Java 言語が最適な選択ではない可能性があることです。したがって、ネイティブメソッドにより、Java プログラムは Java ランタイムの境界を超越し、JVM を効果的に拡張できるようになります。

仮想マシンスタックと同様に、ローカルメソッドスタックでも、スタック深度がオーバーフローしたり、スタック拡張に失敗したりすると、StackOverflowError および OutOfMemoryError 例外がスローされます。

スレッド共有: ヒープ

Java ヒープは、仮想マシンによって管理されるメモリの最大の領域です。ヒープはすべてのスレッドで共有されるメモリ領域であり、仮想マシンの起動時に作成されます。このメモリ領域の唯一の目的はオブジェクトインスタンスを格納することであり、「ほぼ」すべてのオブジェクトインスタンスがここにメモリを割り当てます。

注記！ここでは「ほぼ」という言葉を使います。技術の発展により、エスケープ技術など、すべてのオブジェクトインスタンスが実際にヒープに割り当てられるわけではありません。これについては次の記事で説明しますね〜

ヒープはガベージコレクターによって管理されるメモリ領域であるため、一部の資料では「GC ヒープ」(Garbage Collected Heap) とも呼ばれます。

新世代、旧世代、永久世代、エデン空間、From Survivor 空間、To Survivor 空間など、さまざまな用語を聞いたことがあるかもしれません。これらの領域区分は、一部のガベージコレクターの共通の特性または設計スタイルにすぎないことに注意してください。これらは、特定の Java 仮想マシンの固有のメモリレイアウトや、Java 仮想マシン仕様における Java ヒープのより詳細な分割ではなく、この世代別設計を通じてメモリ回復を改善したり、メモリ割り当てを高速化したりするためのものです。

Java 仮想マシン仕様によれば、Java ヒープは物理的には不連続なメモリ空間に存在する可能性がありますが、論理的には連続していると見なされます。これは、ディスク領域を使用してファイルを保存する場合と同様であり、各ファイルを継続的に保存する必要はありません。ただし、大きなオブジェクト (通常は配列オブジェクト) の場合、ほとんどの仮想マシン実装では、単純さと効率的なストレージのために連続したメモリ領域が必要になる可能性があります。

Java ヒープは、固定サイズまたは拡張可能なヒープとして実装できます。現在主流のJava仮想マシンはすべて拡張可能として実装されています（パラメータ-Xmxと-Xmsで設定）

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

スレッド共有: メソッド領域

メソッド領域は、仮想マシンがクラスのロードを完了した後、型情報、定数、静的変数、ジャストインタイムコンパイラによってコンパイルされたコードキャッシュ、およびクラスに関連するその他のデータを格納する領域として簡単に理解できます。

実行時定数プール、フィールドとメソッドのデータ、クラスとインスタンスの初期化やインターフェースの初期化で使用される特殊なメソッドを含むメソッドとコンストラクターのコードなどのクラスごとの構造を格納します。

以下に簡単な例を示します。

メソッド領域自体は実は簡単に理解できるのですが、「Java 仮想マシン仕様」/「Java 仮想マシンの詳細な理解」に記載されている「メソッド領域はヒープ内の論理的な部分である」という文章が、長い間私を混乱させました。

私の理解に基づいて説明させてください。この「メソッド領域はヒープの論理的な一部である」はJDK 8以前には適用されるが、JDK 8には適用されないと思う。

まず、JDK 8 以前の状況を見てみましょう。

JDK 8 より前では、ヒープとメソッド領域は実際に接続されていた、つまり、メソッド領域はヒープの一部であったことがわかります。

ただし、メソッド領域に格納されるものは少し特殊です。過去には、カスタムクラスローダーが一般的に使用されていなかったため、クラスはほぼ「静的」であり、アンロードされてリサイクルされることはほとんどなかったため、クラスは「永続的」であると見なすこともできました (これが永続世代の意味です)。また、クラスは JVM 実装の一部であり、プログラムによって作成されるものではないため、ヒープと区別するために、クラス情報を格納するための「メソッド領域」という名前が付けられています。メソッド領域を「非ヒープ」と呼ぶ人もいます。

メソッド領域と非ヒープ領域はどちらも単なる論理的な概念であることに注意してください。 JDK 8 より前では、具体的な実装方法は永続的な生成でした。

永続世代は HotSpot 仮想マシンによって実装されますが、BEA JRockit、IBM J9 などの他の仮想マシン実装では永続世代の概念はありません。

永続世代は連続したメモリ空間です。 JVM を起動する前に -XX:MaxPermSize の値を設定することで、永続世代のサイズを制御できます。 32 ビットマシンのデフォルトの永続世代サイズは 64 MB で、64 ビットマシンの場合は 85 MB です。

永久世代のガベージコレクションと古い世代のガベージコレクションは結合されています。いずれかの領域がいっぱいになると、両方の領域でガベージコレクションが実行されます。

明らかに、この設計は良いアイデアではありません。?XX:MaxPermSize を通じて永続世代のサイズを設定できるためです。クラスのメタデータが設定サイズを超えると、プログラムはメモリ不足になり、メモリオーバーフローエラー (java.lang.OutOfMemoryError: PermGen space) が発生します。

また、永久世代によって仮想マシンごとにパフォーマンスが異なるメソッドもごくわずかです (たとえば、String の intern() メソッドは、操作中に文字列定数プールに文字列を手動で追加できます。JDK1.7 より前の HotSpot 仮想マシンでは、文字列定数プールは永久世代に格納されます)。

それでは、HotSpots が JDK 8 で permanent 世代を放棄し、メタスペースを使用してメソッド領域を実装した 2 つの主な理由をまとめてみましょう。

永久世代のガベージコレクションと古い世代のガベージコレクションは結合されているため、いずれかの領域がいっぱいになると、両方の領域がガベージコレクションされ、OOM の可能性が高まります。
String の intern() メソッドなどのいくつかのメソッドは、永続的な生成のために、異なる仮想マシンで異なる動作をする可能性があり、これはコードの移行には役立ちません。

では、Metaspace とは一体何なのでしょうか。また、Metaspace はメソッド領域とどう違うのでしょうか。

メタスペースと永続世代の最大の違いは、メタスペースはヒープと連続しなくなり、ネイティブメモリ内に存在することです。

ランタイムデータ領域の比較を以下に示します。

メタスペースはローカルメモリ内に存在するため、ローカルメモリが十分にある限り OOM は発生せず、永続世代に java.lang.OutOfMemoryError: PermGenspace は発生しません。

ランタイム定数プール

ランタイム定数プールはメソッド領域の一部です。上で述べたように、メソッド領域にはクラス情報が含まれています。クラス情報を記述する Class ファイルには、クラスバージョン、フィールド、メソッド、インターフェイスなどの記述情報に加えて、さまざまなリテラル (リテラルは、テキスト文字列、final として宣言された定数値など、Java 言語レベルでの定数の概念に相当します) やコンパイル中に生成されるシンボル参照を格納するために使用される定数プールテーブルも含まれています。一部の記事では、クラス定数プールテーブルを静的定数プールと呼んでいます。

それらはすべて定数プールです。定数プールテーブルとランタイム定数プールの関係は何ですか?ランタイム定数プールの目的は何ですか?

ランタイム定数プールは、実行時にクラス定数プールテーブル内のシンボリック参照を直接参照に解決できます。簡単に言えば、クラス定数プールテーブルは一連のインデックスに相当します。ランタイム定数プールは、これらのインデックスを使用して、対応するメソッドまたはフィールドの型情報、名前、および記述子情報を検索します。

なぜ定数プールが必要なのでしょうか?主にシステムパフォーマンスに影響を与えるオブジェクトの頻繁な作成と破棄を回避し、オブジェクトの共有を実現します。文字列定数プールを例に挙げます。文字列は Java のクラスであるため、他のオブジェクトの割り当てと同様に、時間と領域のコストが高くなります。最も基本的かつ一般的に使用されるデータ型であるため、大量の文字列を頻繁に作成すると、プログラムのパフォーマンスに大きな影響を与えます。このため、JVM は、パフォーマンスを向上させ、メモリのオーバーヘッドを削減するために、文字列定数をインスタンス化するときにいくつかの最適化を行います。

文字列定数プール文字列プールは文字列用に開かれ、キャッシュ領域として理解できます。
文字列定数を作成するときは、まず文字列が文字列定数プールに存在するかどうかを確認します。
文字列が文字列定数プールに存在する場合、再インスタンス化なしで参照インスタンスが直接返されます。存在しない場合は、文字列がインスタンス化され、プールに配置されます。

JDK 1.7 の前後では文字列定数プールの場所が変更されていることに注意してください。次の表を参照してください。

最後に、この質問の暗唱バージョンを以下に示します。

インタビュアー: JVMランタイムデータ領域について教えてください

Veal: Java プログラムの実行中、JVM は管理するメモリを複数の異なるデータ領域に分割します。スレッドによって共有される領域はメソッド領域とヒープであり、スレッドにプライベートな領域は仮想マシンスタック、ローカルメソッドスタック、およびプログラムカウンターです。

いわゆるスレッドプライバシーとは、各スレッドが独自のスペースを作成することを意味します。各スレッド間のプライベートスペースは互いに影響を及ぼさず、独立して保存されます。

まず、3 つのスレッドプライベート領域について説明します。

プログラムカウンター: プログラムカウンターは、現在のスレッドによって実行されたバイトコードの行番号インジケーターと見なすことができる、小さなメモリ空間です。バイトコードインタープリタが動作する場合、このカウンタの値を変更して、次に実行するバイトコード命令を選択します。分岐、ループ、ジャンプ、例外処理、スレッド回復などの基本機能はすべて、このカウンターに依存して完了します。

このメモリ領域は、Java 仮想マシン仕様で OutOfMemoryError 条件が指定されていない唯一の領域です。

仮想マシンスタック: 仮想マシンスタックは、実際にはスタックフレームが 1 つずつ構成されています。スタックフレームは、Java メソッド実行のメモリモデルを記述します。つまり、各メソッドは実行時にスタックフレームを同期的に作成し、ローカル変数テーブル、オペランドスタック、ダイナミックリンク、メソッドの戻りアドレスなどの情報を格納するために使用されます。各メソッドが呼び出されてから実行されるまでのプロセスは、スタックフレームが仮想マシンスタックにプッシュされてからスタックからポップされるまでのプロセスに対応します。

仮想マシンスタックのメモリ領域に 2 つの異常状態があります。

スレッドが要求したスタックの深さが仮想マシンで許可されている深さより大きい場合、StackOverflowError例外がスローされます（スタックオーバーフロー）
使用されている JVM が仮想マシンスタック容量の動的な拡張をサポートしている場合、スタック拡張中にメモリ不足が要求されると、OutOfMemoryError 例外がスローされます。

ローカルメソッドスタック: ローカルメソッドスタックと仮想マシンスタックは基本的に同じ機能を持ちます。唯一の違いは、ローカルメソッドスタックは仮想マシンによって使用されるネイティブメソッドを提供するのに対し、仮想マシンスタックは仮想マシンによって実行される Java メソッド (つまり、バイトコード) を提供するという点です。

ローカルメソッドスタックは、スタック深度がオーバーフローするか、スタック拡張が失敗した場合にも、StackOverflowError および OutOfMemoryError 例外をスローします。

スレッドが共有する 2 つの領域について説明します。

ヒープ: Java ヒープは、仮想マシンによって管理されるメモリの最大の領域です。ヒープはすべてのスレッドで共有されるメモリ領域であり、仮想マシンの起動時に作成されます。このメモリ領域の唯一の目的はオブジェクトインスタンスを格納することであり、ほぼすべての新しいオブジェクトインスタンスにここでメモリが割り当てられます。

Java ヒープは、固定サイズまたは拡張可能なサイズのいずれかとして実装できます。オブジェクトインスタンスの割り当てを完了するためのメモリがヒープ内に存在せず、ヒープをそれ以上拡張できない場合、JVM は OutOfMemoryError 例外をスローします。

メソッド領域: メソッド領域は、仮想マシンがクラスのロードを完了した後に、型情報、定数、静的変数、ジャストインタイムコンパイラによってコンパイルされたコードキャッシュ、およびクラスに関連するその他のデータが格納される場所です。

JDK 8 より前では、ヒープとメソッド領域は実際には接続されていたか、メソッド領域は実際にはヒープの一部でした。 HotSpot 仮想マシンによって提供される特定の実装は、連続したメモリ空間である永続的な世代です。永久世代のガベージコレクションと古い世代のガベージコレクションはバインドされているため、いずれかの領域がいっぱいになると、両方の領域をガベージコレクションする必要があり、OOM の可能性が高まります。さらに、String の intern() メソッドなどのいくつかのメソッドは、永続的な生成のため、異なる仮想マシンではパフォーマンスが異なり、コードの移行には適していません。これら 2 つの理由により、HotSpots は JDK 8 以降、メソッド領域の実装をメタスペースに置き換えました。

メタスペースとパーマネントジェネレーションの最大の違いは、メタスペースはヒープと連続しなくなり、ネイティブメモリ内に存在することです。つまり、ネイティブメモリが十分である限り、OOMは発生しません。

<<: 統合アーキテクチャ: 分散データベースを再定義し、コアビジネスシステムに参入

>>: 魅力的なクラウドイノベーション16選