JVMの原則の分析、誰もが良いと言った

[[317032]]

1 JVM とは何ですか?

JVM は Java Virtual Machine の略称で、実際のコンピュータ上でさまざまなコンピュータ機能をシミュレートすることで実現されます。バイトコード命令セット、レジスター セット、スタック、ガベージ コレクション ヒープ、およびストレージ メソッド ドメインで構成されます。 JVM はオペレーティング システム プラットフォームに関連する情報をシールドするため、Java プログラムは Java 仮想マシン上で実行されるターゲット コード (バイトコード) を生成するだけで済み、変更せずに複数のプラットフォーム上で実行できます。これは、Java が「一度コンパイルすればどこでも実行できる」理由でもあります。

2 JRE、JDK、JVMの関係

JRE (Java Runtime Environment) は Java プラットフォームであり、すべてのプログラムは JRE の下で実行する必要があります。 JVM および Java コア クラス ライブラリとサポート ファイルが含まれています。

JDK (Java Development Kit) は、Java プログラムをコンパイルおよびデバッグするために使用される開発キットです。 Java ツール (javac/java/jdb など) と Java ベースのクラス ライブラリ (java API) が含まれています。

JVM (Java 仮想マシン) は JRE の一部です。 JVM の主な仕事は、独自の命令セット (つまりバイトコード) を解釈し、それをローカル CPU 命令セットと OS システム コールにマッピングすることです。 Java 言語は複数のプラットフォームで実行され、オペレーティング システムごとに JVM マッピング ルールが異なるため、オペレーティング システムから独立し、クロスプラットフォームのパフォーマンスを実現します。

次の図は、JDK、JRE、JVM の関係を示しています。

概要: JDK を使用して JAVA プログラムを開発した後 (JAVA API を呼び出す)、Java プログラムは JDK のコンパイラ (javac) を介して Java バイトコードにコンパイルされます。これらのバイトコードは JRE 上で実行され、JVM はそれらを解析して、実際のオペレーティング システムの CPU 命令セットと OS のシステム コールにマッピングします。

3 JVM の原則

Java アーキテクチャの概要:

• クラス ローダー: .class ファイルをロードするために使用されます。
• 実行エンジン: バイトコードまたはネイティブ メソッドを実行するために使用されます。
• ランタイム データ領域: メソッド領域、ヒープ、Java スタック、PC レジスタ、ローカル メソッド スタック。

JVM ライフサイクルの概要:

Javaインスタンスは独立して実行されるJavaプログラム（プロセスレベル）に対応する。

1. 開始します。 Java プログラムを起動すると、JVM インスタンスが作成されます。 public static void main(String[] args) 関数を持つクラスは、JVM インスタンスの実行の開始点として機能します。

2. 走る。 main() はプログラムの最初のスレッドの開始点であり、他のスレッドはこのスレッドから開始できます。 JVM 内には、デーモン スレッドと非デーモン スレッドの 2 種類のスレッドがあります。 main() は非デーモン スレッドに属します。デーモン スレッドは通常、JVM によって使用されます。プログラムは、作成されたスレッドがデーモン スレッドであることを指定できます。

3. 失踪。プログラム内のすべての非デーモン スレッドが終了すると、JVM は終了します。セキュリティ マネージャーが許可している場合、プログラムは Runtime クラスまたは System.exit() を使用して終了することもできます。

JVM 実行エンジン インスタンスは、スレッド レベルのユーザーの実行中のプログラム スレッドに対応します。

Java クラスローダー:

Java のクラスをロードするプロセス:

1. ロード: バイナリ バイトコードを見つけて JVM にロードする役割を担います。 JVM は、クラス名、クラスが配置されているパッケージ名、および ClassLoader を通じてクラスのロードを完了します。したがって、ロードされたクラスを識別するには、クラス名 + パッケージ名 + ClassLoader インスタンス ID を使用します。

2. リンク: バイナリ バイトコードの形式のチェック、ロード クラス内の静的変数の初期化、クラスで呼び出されるインターフェイスの解析を担当します。

検証が完了すると、JVM はクラス内の静的変数を初期化し、デフォルト値を割り当てます。

最後に、クラス内のすべてのプロパティとメソッドが検証のために比較され、呼び出されるプロパティとメソッドが存在し、アクセス権限 (private、public など) があることを確認します。そうしないと、NoSuchMethodError や NoSuchFieldError などのエラー メッセージが発生します。

3. 初期化: 静的初期化コード、コンストラクター コード、およびクラス内の静的プロパティの初期化を実行します。初期化プロセスは、次の 4 つの状況でトリガーされます。

• 新規呼び出し
• リフレクションはクラス内のメソッドを呼び出す
• サブクラスはinitializeを呼び出す
• JVM起動プロセスは初期化クラスを終了します

JVM クラスの読み込み順序:

階層

1. Booststrap クラスローダー

C++ で実装された ClassLoader は、JVM の起動時に初期化され、$JAVA_HONE の jre/lib/rt.jar (Sun JDK 実装) 内のすべてのクラス ファイルをロードします。この jar には、Java 仕様で定義されているすべてのインターフェースと実装が含まれています。

2. 拡張クラスローダー

JVMはこのクラスローダーを使用して、拡張機能を備えたいくつかのjarパッケージをロードします。

3.システムクラスローダー

JVM はこの ClassLoader を使用して、起動パラメータで指定された ClassPath 内の jar パッケージとディレクトリをロードします。 Sun JDK の ClassLoader に対応するクラス名は AppClassLoader です。

4. ユーザー定義クラスローダー

ユーザー定義の ClassLoader は、ClassLoader 抽象クラスを継承し、Java 開発者によって実装される ClassLoader です。カスタムベースの ClassLoader を使用すると、ClassPath にない jar やディレクトリをロードできます。

委任モード

JVM がクラスをロードすると、下位レベルのローダーが上位レベルのクラスローダーにタスクを渡します。上位レベルのローダーは、クラスがその名前空間にロードされているかどうかを確認します。ロードされている場合は、クラスを直接使用します。ロードされていない場合は、最上部に到達するまで上方へ委任を続けます。確認後、逆の手順で積み込みます。ブートストラップ ローダーがこのクラスを見つけられない場合は、このクラスが見つかるまで下位に委任します。クラスは異なるクラスローダーによってロードできます。

可視性の制限: 下位レベルのローダーは上位レベルのローダー内のクラスを表示できますが、その逆はできません。委任は下から上にのみ行うことができます。

クラスのアンロードは許可されていません: クラス ローダーはクラスをロードできますが、クラスをアンロードすることはできません。ただし、クラスローダーは作成および削除できます。

JVM実行エンジン

クラス ローダーがバイトコードをメモリにロードした後、実行エンジンは Java バイトコードを Java バイトコード単位で読み取ります。 Java バイトコードはマシンでは読み取れないため、バイトコードをプラットフォームに依存するマシン コードに変換する必要があります。このプロセスは実行エンジンによって完了します。

JVM は、メソッドを実行するときに実行する 4 つの命令を提供します。

• invokestatic: クラスの静的メソッドを呼び出します。
• invokevirtual: オブジェクト インスタンスのメソッドを呼び出します。
• invokeinterface: 呼び出し用のインターフェースとしてプロパティを定義します。
• invokespecial: JVM はオブジェクトを初期化し (Java コンストラクターのメソッドは:)、オブジェクト インスタンスのプライベート メソッドを呼び出します。

主な実行回数:

• 解釈、ジャストインタイム実行、適応最適化、チップレベルでの直接実行。
• 説明: JVMの第1世代に属します
• ジャストインタイムコンパイル（JIT）はJVMの第2世代に属します。

適応型最適化 (現在 Sun の HotspotJVM がこのテクノロジを使用しています) は、第 1 世代および第 2 世代の JVM の経験を活かし、2 つの組み合わせを採用し、すべてのコードを解釈して実行し、コード実行を監視し、頻繁に呼び出されるメソッドのバックグラウンド スレッドを開始し、それらをネイティブ コードにコンパイルして最適化します。メソッドが頻繁に使用されなくなった場合、コンパイルされたコードはコンパイルされずに解釈されたままになります。

Java ランタイム データ領域

PCレジスター

各スレッドが次に実行する JVM 命令を格納するために使用されます。メソッドがネイティブの場合、PC レジスタには情報は保存されません。 Java マルチスレッドの場合、異なるスレッド コンテキスト間の切り替えを容易にするために、各スレッドには独自の PC があります。

JVMスタック

JVM スタックはスレッドプライベートです。スレッドごとに JVM スタックが作成されます。 JVM スタックには、現在のスレッドの基本型のローカル変数 (Java で定義されている 8 つの基本型: boolean、char、byte、short、int、long、float、double)、いくつかの戻り値、およびスタック フレームが格納されます。基本型以外のオブジェクトは、JVM スタック上のヒープを指すアドレスにのみ格納されます。

ヒープ

これは、JVM がオブジェクト インスタンスと配列値を格納するために使用する領域です。 Java で new によって作成されたすべてのオブジェクトのメモリがここに割り当てられ、ヒープ内のオブジェクトのメモリは GC による再利用を待つ必要があると考えられます。

ヒープは JVM の起動時に作成されます。ヒープにはさまざまなオブジェクトが格納されており、これらのオブジェクトは「ガベージ コレクター」と呼ばれることが多い自動ストレージ管理システム (Automatic Storage Management System) によって管理されます。これらのオブジェクトは明示的に破棄する必要はなく、破棄することもできません。

JVMはヒープを新世代と旧世代の2つの部分に分割します。

ヒープは JVM 内のすべてのスレッドによって共有されるため、ヒープ上のすべてのオブジェクト メモリ割り当てにはロックが必要となり、新しいオブジェクトに大きなオーバーヘッドが発生します。

オブジェクト メモリ割り当ての効率を向上させるために、Sun Hotspot JVM は作成されたすべてのスレッドに対して独立した領域 TLAB (スレッド ローカル割り当てバッファー) を割り当てます。スペースのサイズは、実行状況に基づいて JVM によって計算されます。 TLAB にオブジェクトを割り当てるときにロックは必要ありません。したがって、スレッド オブジェクトにメモリを割り当てる場合、JVM は TLAB に割り当てようとします。この場合、JVM でオブジェクト メモリを割り当てるパフォーマンスは基本的に C の場合と同じですが、オブジェクトが大きすぎる場合は、ヒープ領域を使用して直接割り当てる必要があります。

TLAB は新世代の Eden Space でのみ動作するため、Java プログラムを作成する場合、通常は大きなオブジェクトよりも小さなオブジェクトを複数割り当てる方が効率的です。

新しく作成されたオブジェクトはすべて Young Generation に保存されます。 Young Generation のデータが 1 回以上の GC を生き残った場合、Old Generation に転送されます。新しいオブジェクトは常に Eden Space に作成されます。

方法領域

Sun JDK では、この領域は PermanetGeneration (永続世代とも呼ばれる) に対応します。

メソッド領域には、ロードされたクラスの情報 (名前、修飾子など)、クラス内の静的変数、クラス内で final 型として定義された定数、クラス内のフィールド情報、クラス内のメソッド情報が格納されます。開発者がプロ​​グラム内の Class オブジェクトの getName や isInstance などのメソッドを通じて情報を取得する場合、これらのデータはすべてメソッド領域から取得されます。メソッド領域もグローバルに共有され、特定の条件下で GC されます。メソッド領域に必要なメモリが許容サイズを超えると、OutOfMemory エラー メッセージがスローされます。

ランタイム定数プール

クラス内の固定定数情報やメソッド、フィールド参照情報などを格納し、その領域はメソッド領域から割り当てられます。

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

JVM は、ローカル メソッド ヒープを使用してネイティブ メソッドの実行をサポートします。この領域は、各ネイティブ メソッド呼び出しのステータスを保存するために使用されます。

JVM ガベージ コレクション

GC の基本原則: メモリ内で使用されなくなったオブジェクトはリサイクルされます。 GC でリサイクルに使用される方法はコレクターと呼ばれます。 GC はある程度のリソースと時間を消費するため、Java はオブジェクトのライフサイクルの特性を分析した後、新しい世代と古い世代のオブジェクトを収集し、GC によってアプリケーションに発生する一時停止を可能な限り短縮します。

新世代オブジェクトの収集はマイナーGCと呼ばれる

古い世代のオブジェクトのコレクションはフルGCと呼ばれます

プログラム内で System.gc() を積極的に呼び出すことによって強制される GC は Full GC です。

GC は、さまざまなオブジェクト参照タイプをリサイクルするためにさまざまな方法を使用します。 JVM オブジェクト参照は 4 つのタイプに分けられます。

強い参照: デフォルトでは、すべてのオブジェクトは強い参照を使用します (このオブジェクト インスタンスに他のオブジェクト参照がない場合、GC 中にリサイクルされます)

ソフト参照: ソフト参照は、Java で提供される、キャッシュ シナリオに適したアプリケーションです (メモリが不足している場合にのみ GC されます)

弱参照: GC 中に GC によってリサイクルされます。

ファントム参照: ファントム参照は、オブジェクトが GC されたかどうかを確認するためにのみ使用されます。