JVMクラスローディングメカニズムに関しては、この記事で十分です

序文

1ヶ月間更新してませんでした。今月はいろいろなことが起こり、更新頻度が大幅に減少しました。どれだけ努力しても、技術研究で遅れをとることはできません!

JVMとは

通常、コードは .java ファイルに記述します。これらをマシンにデプロイして実行するにはどうすればよいでしょうか? jar または war パッケージにパッケージ化し、デプロイして実行します。

jar パッケージの内容を読んだことがあれば、作成したすべての .java ファイルが .class ファイルにコンパイルされていることがわかります。

ここで非常に重要なステップであるコンパイルが行われます。つまり、作成したプログラムを JVM が理解できるファイル形式に変換します。

各クラスは、内部クラスも含めて .class ファイルにコンパイルされることに注意してください。つまり、各 .class ファイルはコード内の 1 つのクラスにのみ対応します。

クラスのライフサイクル

クラスが JVM メモリにロードされてからメモリからアンロードされるまでのライフサイクルは、ロード -> 検証 -> 準備 -> 解析 -> 初期化 -> 使用 -> アンロードに分けられます。

これを一つずつ説明しましょう:

負荷

jar パッケージが生成されると、作成したすべてのプログラムは、JVM が理解できる .class 形式にコンパイルされます。この時点で、コンパイルされた .class ファイルを jvm にロードする必要があります。この時点で、「クラスローダー」という概念が存在します。下記の通りです。

次の質問は、クラスローダーが .class を JVM にロードするのはいつでしょうか?つまり、どのような状況でクラスがロードされるのでしょうか?

jar パッケージの実行中は、エントリメソッドとして main() メソッドが指定されます。まず、main() メソッドが配置されているクラスが jvm にロードされ、コード実行で new が発生すると、オブジェクトは引き続き jvm にロードされます。

まとめると、コード内でこのクラスを使用する必要がある場合、クラスは JVM にロードされます。

確認する

これはあまり深く理解する必要はありません。非常に単純な真実です。どのような猫や犬でも JVM にロードできるわけではありません。そうでないと、混乱が生じます。したがって、この段階では、ロードされた .class ファイルが指定されたルールを満たしているかどうかを確認します。

興味深いのは、すべての .class ファイルが非常にロマンチックであることです。すべての .class ファイルは、Coffee Baby を意味する 8 桁の 16 進文字 0×CAFEBABE で始まるからです。ロマンチックですよね？検証フェーズの最初のステップは、.class ファイルが CoffeeBaby で始まるかどうかを確認することです。

フローチャートは次のように更新できます。

準備する

.class ファイルを jvm に合法的にロードすると、この時点でいくつかの準備作業が行われます。

まず、このクラスにメモリ領域を割り当て、次にクラス変数 (static によって変更される変数) にデフォルトの初期値を割り当てます。ただし、クラス変数も final によって変更された場合は、初期値ではなく特定の値が割り当てられます。

次の 2 つの状況を例に挙げて説明しましょう。

パブリッククラスStudent{
 プライベートスタティック 年齢= 18;
 }
 //この時点で、age 変数にメモリ領域が割り当てられ、初期値 0 が割り当てられます。
パブリッククラスStudent{
 プライベート静的最終int年齢 = 18;
 }
 //age が final によって変更されると、age 変数にメモリ領域が割り当てられ、その値に 18 が割り当てられます。