3年間のJavaバックエンド開発では、JVMを知っておく必要があります

JAVA プログラマーにとって、3 年というのはハードルです。 3 年経っても JVM を勉強していないと、プログラマーとしては役に立たない存在になってしまいます。 JVM 分析はどうですか?

JVM は Java Virtual Machine の略で、JVM 仮想マシンを指します。実際のコンピュータ上でさまざまなコンピュータの機能をシミュレートする架空のコンピュータです。

JVM の存在により、JAVA プログラマーはメモリをいつ解放するかを心配する必要がなくなり、C++ プログラマーのようにメモリの量を心配する必要もなくなります。はい、JVM 仮想マシンはこれらすべての作業を完了するのに役立ちます。それでは、JAVA の JVM についてお話ししましょう。

[[267469]]

まず、JVM モデルを見てみましょう。以前、Baidu のドキュメントを読んだのですが、その中でメソッド領域、ヒープ、スタック、カウンターなど、いくつかの項目について言及されていました。それがなくなってしまい、とても不安だったので、JVM について詳しく理解するための本を読んで、ある程度理解することができました。

『JVM の深い理解』という本では、JVM ランタイムのデータ領域は、メソッド領域、VM スタック、ネイティブ メソッド スタック、ヒープ、プログラム カウンターなど、いくつかの異なる領域に分かれていると説明されています。以下は本からの写真です。

一つずつ説明しましょう。まず、プログラム カウンター (プログラム カウンター レジスタ) について説明します。プログラム カウンターは、実際には次の命令のアドレスを格納するために使用されます。命令を実行するときは、まず命令の位置を把握し、次に命令をレジスタに移動して命令を取得し、プログラム カウンターの格納アドレスを 1 増やしてから、ループで実行する必要があります。また、プログラムカウンタの小さなメモリ領域は「スレッド専用メモリ」となります。

なぜ非公開なのですか?書籍「徹底解説 JVM」では、仮想マシンのマルチスレッド化は、スレッドを順番に切り替えることでプロセッサの実行時間を切り替えることで実現されると述べられています。実のところ、理解するのは非常に難しいです。実際には、プロセッサは 1 つのスレッドの命令のみを同時に実行しますが、その時間は不均一になる可能性があります。最初の 1 分間はスレッド a にあり、次の 1 分間はスレッド b にある可能性があります。ただし、スイッチバックの一貫性を確保するために、各スレッドには独立したプログラム カウンターがあり、影響がないように独立して保存されます。つまり、これは「スレッドプライベートメモリ」です。

プログラム カウンターには他にもいくつかの機能があります。

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

これら3つの文を個別に説明しましょう。これは、Java 仮想マシンを深く理解するための原文です。最初の文は非常にわかりやすいようです。 2番目の文について話しましょう。

このカウンターはバイトコード命令のアドレスを記録しますが、ネイティブ（ネイティブメソッド）であるため、たとえば、(System.currentTimeMillis()) は C を通じて実装されており、実行されるバイトコード命令にコンパイルせずにシステムを通じて直接呼び出すことができる場合、それはプログラム カウンターと同等です。記録しない場合は、カウンターの値は空である必要があります。

3番目の文については、小さなコードをコンパイルして逆コンパイルして確認してみましょう。

実際その通りです。

パブリッククラステスト{   intテスト(){ int a = 10; //0 ...... int b = 20; //3....... int c = 30; //6...... (a+b)*cを返します。 //11.... 13.... 14...加算、減算、乗算、除算の演算を実行します } }

上記の0、2、3、5、6、8...は命令のオフセットアドレスです。 Bipush はプッシュ命令です。テスト メソッドが実行されると、スレッドは対応するプログラム カウンターを作成し、命令アドレス 0、2、3、5、6、8... をカウンターに格納します。したがって、カウンターで変化するものはメモリのサイズではなく、オーバーフローすることはありません。

JAVA仮想マシンスタック（VMスタック）についてお話しましょう

スレッドはプライベートであり、スレッドと同じライフサイクルを持ちます。この仮想マシン スタックは、JAVA メソッド実行のメモリ モデルを記述し、ローカル変数、オペランド スタック、メソッド終了などの情報を格納するために使用されます。上記の bipush は push 命令です。ここで注目すべき最も重要な点は、どのようなデータが保存されるかということです。ローカル変数には既知の基本的なデータ型が含まれており、オブジェクト参照はアドレスです。

仮想マシンの仕様には、次の 2 つの異常な状態があることも記載されています。

• 1 つは StackOverflowError 例外、スタック メモリ オーバーフローです。これは確かに簡単に理解できます。つまり、スタック メモリが不足しており、要求スレッドが大きすぎるということです。 (固定長スタック)
• 動的拡張プロセス中に要求された長さがまだ不十分な場合は、別の例外 OutOfMemoryError がスローされます。

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

これは仮想マシン スタックと非常によく似ていますが、違いは、仮想マシン スタックは JAVA メソッドを実行するのに対し、ローカル メソッド スタックはネイティブ メソッドである点です。他に違いはなく、スローされる例外も同じです。

JAVA ヒープ (heap) については、JVM の本にも記載されています。ヒープは、JAVA 仮想マシン内でメモリが最も多く占める場所です。また、すべてのスレッドで共有されるメモリ領域でもあります。ヒープ メモリは主にオブジェクト インスタンスを格納するために使用されます。

ほぼすべてのオブジェクト インスタンスはここでメモリを割り当てます。 JAVA ヒープは、ガベージ コレクターによって管理される主要な領域です。さて、ここからが本題です。面接で最も多く聞かれるガベージコレクションの仕組みについて詳しく説明します。

メモリのリサイクルは現在、世代別アルゴリズムを使用して実行されており、ヒープ、新世代、旧世代についても同様であり、2 つのガベージ コレクション メカニズムは異なるリサイクル メカニズムを使用します。新しい世代では、ガベージ コレクションが実行されるたびに、多数のオブジェクトが消滅し、少数のオブジェクトのみが生き残ることがわかります。この場合、コピー アルゴリズムが使用され、少数の生き残ったオブジェクトをコピーするコストのみを支払うことでコレクションを完了できます。

古い世代では、オブジェクトの生存率が高く、割り当てるための余分なスペースがないため、リサイクルには「マークスイープ」または「マークコンパクト」アルゴリズムを使用する必要があります。リサイクルのメカニズムについて話すには、まずヒープ パーティションを見てみましょう (開始と終了は絶対的なものではなく、オブジェクトが配置されている場所によって異なります。GC の回数が異なれば、開始と終了もそれに応じて変わります)

仕切りが一目でわかります。アルゴリズムの実装を勉強しましょう。

マイナーGC: GC新世代、

フルGC: 旧世代GC、

新しい世代のオブジェクトの生存率は比較的低いため、通常はレプリケーション アルゴリズムが使用されます。古い世代の生存率は一般的に高く、リサイクルには「マークスイープ」または「マークコンパクト」アルゴリズムが一般的に使用されます。

それが何を意味するのか理解するのに数日かかりました。私の意見を述べて、絵を描いてみましょう。

マイナーGC:

新しいオブジェクトを作成するたびに、まずそれを新しい世代の Enden 領域に配置します。これは、最初は次のようになります。

そして、Enden が使い果たされると、リサイクルできるアイテムが残ります。

その後、生き残ったオブジェクトは Survior1 (from) にコピーされ、リサイクルされるオブジェクトはリサイクルされるのを待機します。

次に、エンデンエリアをクリアしてリサイクルします

このようにして最初のGCが完了し、

Enden がいっぱいになると、GC が再度実行されます。

最初はこんな感じでした

そして、EndenとSurvoir1の内容がSurviorにコピーされ、

そうなるとエンデンとサバイバーはリサイクルされる

すると、Enden を通過するものは移動回数が少ないものと同等になり、Survior1 を通過するものは 2 回移動するものと同等になります。

このようにして、新しい世代の GC が 2 回実行されます。

Endenが再度使用されると、Survior2からSurvior1にコピーされます。

コレクション後、Survior1が変更されました。オブジェクト 1 は Enden から直接コピーされ、オブジェクト 2 は Enden -->Survior2 -->Survior1 からコピーされ、オブジェクト 3 は Enden -->Surivior1 -->Survior2 -->Survior1 からコピーされます。ステップごとに実行すると、新しい世代の GC になります。

この場合、なぜ古い世代がまだ存在するのでしょうか?実際、GC 実行中に一部のオブジェクトがリサイクルされなかった場合、移動回数は継続的に蓄積されます。 Surior (from) から Surior (to) への各移動は、別の移動を追加することと同じです。一定回数（デフォルトは15）に達すると、古い世代に移動されます。したがって、リサイクルされないオブジェクトはありませんが、この数は設定できます。

-XX:最大テンリングしきい値

こんな感じです

実際、上記はほんの一例です。オブジェクトが大きすぎて保存できない場合は、古い世代に直接格納されます。

長寿世代をデフォルトにしている人もいて、高齢世代に入る人もいます。

さらに、このレプリケーション アルゴリズムのガベージ コレクション メカニズムは、比較的メモリを浪費します。メモリ領域の一部がアイドル状態で動作していない場合は、その利点は明らかで、シンプルで効率的です。

上記は、GC のガベージコレクションにおける新世代コピーアルゴリズムの分析です。私たちは今、新世代のマイナー GC について多くのことを知っています。上記は個人的な見解です。絵は比較的鮮明でわかりやすいです。間違いがありましたら、同僚の方々にご指摘いただければ幸いです。