devkuma – JVM

JVM メモリ構造

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

Java で使用されるメモリモデルの構造を理解しておくと、Java プログラムを作成するうえで大いに役立つ。

JVM(Java Virtual Machine)

Java プロセスは JVM という仮想システム上で実行される。この構造により、コンパイルされた Java クラスファイル（bytecode）をさまざまな OS 環境で実行できる。

Java バイトコード(Java bytecode)

Java バイトコード（Java bytecode）とは、Java 仮想マシンが理解できる言語に変換された Java ソースコードを意味する。 Java コンパイラによって変換されるコードの命令サイズが 1 byte であるため、Java バイトコードと呼ばれている。この Java バイトコードの拡張子は `.class` である。 Java バイトコードは、Java 仮想マシンさえインストールされていれば、どのオペレーティングシステムでも実行できる。

Java メモリ領域の構造

すべての Java プログラムは Java 仮想マシン（JVM）を通じて実行される。Java プログラムが実行されると、JVM はそのプログラムを実行するために必要なメモリをオペレーティングシステムから割り当てられる。

JVM は割り当てられたメモリを効率よく使うため、用途に応じて次のように複数の領域に分けて管理する。

Runtime Data Area はオペレーティングシステムから割り当てられたメモリ領域であり、Java アプリケーションを実行するときに使用されるデータを格納する領域である。
大きく Method Area、Heap Area、Stack Area、PC Register、Native Method Stack に分けられる。

メソッド(method)領域 / Static 領域

メソッド領域は、Java プログラムで使用されるクラスに関する情報と、クラス変数（static variable）が保存される領域である。
JVM は Java プログラムで特定のクラスが使用されると、そのクラス、つまり Java バイトコードであるクラスファイル（*.class）を読み込み、ロードされたクラスとインターフェースに対するランタイム定数プール（runtime constant pool）、メンバ変数（フィールド）、クラス変数（static 変数）、コンストラクタ、メソッドを保存する。

この領域に保存された内容は、プログラム開始前にロードされ、プログラム終了時に消滅する。
ランタイム定数プールには、コンパイル時に分かっている数値リテラルから、実行時に解決される必要があるメソッドやフィールドの参照まで、さまざまな定数が含まれる。

リテラル（literal）は、コンピュータサイエンス分野で固定された値を意味する。定数は変わらない変数を指し、リテラルは変わらない値（データ）を指す。

ヒープ(heap)領域

ヒープ領域は、Java プログラムで使用されるすべてのクラスオブジェクト（インスタンス）変数が保存される領域であり、JVM が管理するプログラム上でデータを保存するために実行時に動的に割り当てて使用する領域である。

プロセス実行中に動的に変化するデータは、基本的にここに割り当てられる。つまり、Java プログラムで new 演算子を使ってインスタンスが生成されると、JVM はそのインスタンスの情報をヒープ領域に保存する。
ヒープ領域は、メモリの低いアドレスから高いアドレス方向へ割り当てられる。

そして、スタック領域の変数がヒープ領域のインスタンスを参照していたものの、以後参照しなくなった場合、そのインスタンスは Java 仮想マシンのガベージコレクションによって削除される。

ガベージコレクションは、インスタンスが参照されなくなるたびに実行されるわけではない。そうすると、ガベージコレクションの呼び出しだけで多くのリソースを使うことになり、プログラムの性能が低下する。そのため、ガベージコレクションアルゴリズムに従って実行される。

ヒープ領域の使用期間およびスレッド共有範囲は次のとおりである。

オブジェクトがこれ以上使用されない、または明示的に null 宣言された場合
GC（Garbage Collection）の対象
構成方法や GC 方法は JVM ベンダーごとに異なる場合がある。
すべてのスレッドで共有する。

長時間同じプロセスとして実行されるアプリケーションでは、このヒープ領域のメモリ使用を最適化することが重要である。割り当てるサイズを指定するオプションは次のとおりである。

-Xms20m -Xmx100m

上記のように指定すると、次の設定になる。

ヒープ領域に割り当てるメモリの初期サイズ: 20MB
ヒープ領域に割り当てるメモリの最大サイズ: 100MB

スタック(stack)領域

スタック領域は、Java プログラムでメソッドが呼び出されるときに、そのメソッドのスタックフレームが保存される領域である。

JVM は Java プログラムでメソッドが呼び出されると、メソッド呼び出しに関係するローカル変数とパラメータをスタック領域に保存する。このようにスタック領域はメソッド呼び出しとともに割り当てられ、メソッド呼び出しが完了すると消滅する。スタック領域に保存されるメソッド呼び出し情報をスタックフレーム（stack frame）という。

スタック領域は Push でデータを入力し、Pop でデータを出力する。このスタックは LIFO（Last-In First-Out）方式で動作するため、最後に保存されたデータが最初に取り出される。

スタック領域は、メモリの高いアドレスから低いアドレス方向へ割り当てられる。

PC Register

現在実行中の JVM 命令アドレスを持つ。CPU の PC と同じ役割だと言える。
プログラムの実行は CPU がインストラクション（Instruction）を実行することで進む。
CPU はインストラクションの実行中に必要な情報を、CPU 内部の記憶装置であるレジスタに保存する。
演算結果をメモリに渡す前に保存する CPU 内部の記憶装置である。（通常、CPU が命令を処理する過程で必要な情報は Register という CPU 内部の記憶装置に保存される。これは CPU に依存せざるを得ない。そのため、Java の思想を実現するには、この CPU 内 Register の役割を JVM 上の論理的なメモリ領域として実装する必要がある。）

Native Method Stack Area

Java 以外の言語で書かれたネイティブコードのための Stack である。
つまり、JNI（Java Native Interface）を通じて呼び出される C、C++ などのコードを実行するためのスタックである。
ネイティブメソッドのパラメータ、ローカル変数などをバイトコードとして保存する。

参考

JVM ヒープメモリ

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

ヒープメモリとは

ヒープ（Heap）メモリは、Java プログラムの実行中に動的に生成されたオブジェクト（new 演算子で生成されたオブジェクトまたはインスタンス）が保存される空間である。
ここに生成されたオブジェクトは、他のオブジェクトのフィールド、またはスタック上に存在する他のメソッドから参照されることがある。参照する変数がなくなると、そのオブジェクトは不要なものとみなされ、Garbage Collector によって割り当てが解除される。

ヒープメモリ領域の役割

ヒープ領域は機能が多様であるため、複数の部分に分けられる。オブジェクトが最初に生成されたときに保存される空間と、オブジェクト生成後に一定時間使用されなければ移動され、ガベージコレクションを実行できるよう分類される空間に分けて管理する。

Java 7 HotSpot JVM

Java 8 HotSpot JVM

Young Generation

新しいオブジェクトが最初に生成されたとき、heap memory 内で配置される空間である。

Young Generation は次のように分けられる。

Eden
- Java オブジェクトが生成されるとすぐに割り当てられるメモリ領域である。つまり、new 演算子で新しく生成されたオブジェクトが配置される。
Survivor1, Survivor2
- 各領域が埋まると、生き残ったオブジェクトは空いている Survivor へ移動する。
- このとき参照がないオブジェクトは Minor GC によって収集される。

Old Generation

Young Generation でガベージコレクションを最後まで生き残ったオブジェクトが Old Generation へ移動する。つまり、古いデータが保存される領域である。
Major GC が実行され、Minor GC より回数は少ない。

Permanent Generation

Permanent Generation は Class または Method Code が保存される領域である。PermGen は Heap 領域に属する。
PermGen は Permanent Generation の略で、JVM がロードしたクラスのメタデータを追跡するために使用する、通常の Java ヒープとは別の特殊なヒープ空間である。
Permanent Generation には、ロードされたクラスの情報など、ある程度変化しないことが保証されるデータが保存される。

デフォルトでは制限されたサイズを持つ。（32-bit JVM: 64MB、64-bit JVM: 82MB）

JVM Argument

-XX:PermSize=N      --> PermGen Default Size を設定。
-XX:MaxPermSize=N   --> PermGen Max Size を設定。

Metaspace Generation

Java 8 が登場して JVM 領域に変化があった。JVM の複数のメモリ領域のうち Permanent Generation メモリ領域がなくなり、Metaspace 領域が作られた。 Metaspace は Java 8 以前の Perm 領域を置き換えるもので、クラスとメソッドのメタデータが保存される領域である。

Metaspace は、Java の Classloader がこれまでロードした Class の Metadata が保存される空間である。
重要なのは、Heap 領域ではなく Native メモリ領域に位置する点である。
デフォルトでは制限されたサイズを持たない。そのため、必要なだけ増え続ける。
Java 8 以降は PermGen 関連の JVM オプションは無視される。

JVM Argument

-XX:MetaspaceSize=N
-XX:MaxMetaspaceSize=N

MetaspaceSize: Metaspace Default Size を設定。
- この設定は JVM が使用するネイティブメモリ量を変更するために使われる。
- システムが基本で提供するものより多くのメモリを使用すると確信できる場合に、このオプションを使うとよい。
MaxMetaspaceSize: Metaspace Max Size を設定。
- この設定は metaspace の最大メモリ量を変更するために使われる。
- アプリケーションをサーバーで動作させるときにメモリ領域を調整したい場合や、メモリリークが発生してシステム全体のネイティブメモリを使い切らないようにしたい場合に使う。
- もし native メモリがいっぱいになっているにもかかわらず、アプリケーションがさらにメモリを要求すると java.lang.OutOfMemoryError: Metadata space が発生する。
- 設定を指定しなければ制限は設けられない。

Permanent と Metaspace

Java 8 で PermGen は、いくつかの違いはあるものの Metaspace へ名前が変わった。ここで重要なのは、Metaspace にはデフォルトの最大サイズが無制限である点だ。反対に Java 7 以下の PermGen は、デフォルト最大サイズが 32 ビット JVM で 64MB、64 ビット版で 82MB である。もちろん初期サイズと同じではない。Java 7 およびそれ以前のバージョンは、初期 PermGen 空間の約 12-21MB で開始する。

Permanent と Metaspace のデフォルト制限サイズを比較すると次のようになる。

JVM	Default maximum PermGen size (MB)	Default maximum Metaspace size
32-bit client JVM	64	unlimited
32-bit server JVM	64	unlimited
64-bit JVM	82	unlimited

Java 7 以前には、インターンされた文字列（Interned Strings）が PermGen に保持されていた。そのため、悪名高い次のような深刻なエラーが発生していた。

java.lang.OutOfMemoryError: PermGen space

PermGen/Metaspace のサイズを調整する必要があるたびに、JVM は標準ヒープと同じようにサイズを調整する。この空間のサイズ調整には Full GC が必要であり、これは常にコストの高い処理である。多くのクラスがロードされる起動中によく観察できる。特にアプリケーションが多くの外部ライブラリに依存している場合はなおさらである。起動中に Full GC が多く発生する場合、通常はこれが原因である。このような場合、初期サイズを増やすと起動性能が向上することがある。

PermGen から Metaspace への変更の長所と短所は次のとおりである。

長所

PermGen 領域が削除され、heap 領域で使用できるメモリが増えた。
PermGen 領域を削除するために存在していた複雑なコードが削除され、PermGen 領域をスキャンするために消費されていた時間が減少し、GC 性能が向上した。

短所

もはや PermGen 空間が不足することはないが（PermGen が存在しないため）、過度なネイティブメモリを消費してプロセス全体のサイズが大きくなる可能性がある。
問題は、アプリケーションが多くのクラスや文字列をロードする場合、実際にアプリケーションだけでなくサーバー全体を停止させる可能性があることだ。これはネイティブメモリがオペレーティングシステムによってのみ制限されるためである。つまり、そのままサーバーのすべてのメモリを占有し得る。

Java コードによるメモリ管理

Java コードを分析し、ここでメモリをどのように管理するかを見てみよう。

class Person {
    int id;
    String name;

    public Person(int id, String name) {
        this.id = id;
        this.name = name;
    }
}

public class PersonBuilder {
    private static Person buildPerson(int id, String name) {
        return new Person(id, name);
    }

    public static void main(String[] args) {
        int id = 23;
        String name = "John";
        Person person = null;
        person = buildPerson(id, name);
    }
}

main() メソッドに入ると、スタックメモリにこのメソッドのプリミティブ要素と参照を保存するための空間が作成される。
- スタックメモリは整数 id のプリミティブ値を直接保存する。
- Person 型の参照変数 person もスタックメモリに作成され、ヒープ内の実際のオブジェクトを指す。
main() からパラメータ付きコンストラクタ Person(int, String) を呼び出すと、以前のスタックの上に追加メモリが割り当てられる。これには次のものが保存される。
- スタックメモリにある呼び出しオブジェクトの this オブジェクト参照
- スタックメモリのプリミティブ値 id
- ヒープメモリの文字列プールにある実際の文字列を指す、文字列引数 name の参照変数
main メソッドはさらに buildPerson() static メソッドを呼び出しており、このメソッドに対して以前のメソッドの上にスタックメモリで追加割り当てが発生する。これにより、上で説明した方式で変数が再び保存される。
ただし、ヒープメモリは Person 型の新しく生成されたオブジェクト person に対するすべてのインスタンス変数を保存する。

この割り当てについては、次の図で確認する。

出典: https://www.baeldung.com/java-stack-heap

JVM ガベージコレクション

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

ガベージコレクション(Garbage Collection)とは

ガベージコレクション（GC, Garbage Collection）は、Java プロセスでこれ以上使用しないメモリを自動的に解放する JVM の処理である。

Java Runtime 時に Heap 領域へ保存されるオブジェクトは、整理しなければ蓄積し続け、OutOfMemoryError（OOME）が発生する可能性がある。これを防ぐため、JVM では定期的に使用されていないオブジェクトを収集して整理する GC を行う。

C 言語の場合は、malloc()、free() などを使ってメモリを割り当て、手動でメモリを解放しなければならない。この不便さは、Java では GC 技術を使って自動的にメモリを解放することで解消され、開発者をメモリ管理から解放した。

Java はプログラムコードでメモリを明示的に指定して解放しない。オブジェクトを null に指定したり、System.gc() メソッドを呼び出したりする開発者もいる。null に指定することは大きな問題ではないが、System.gc() メソッドの呼び出しはシステム性能に非常に大きな影響を与えるため、System.gc() メソッドは絶対に使用してはならない。

JVM の GC について理解するには、まず JVM メモリ構造を理解する必要がある。JVM メモリ構造については、こちらを参考にしてほしい。

不要なメモリ領域

メモリの使用状況を意識せずにアプリケーションを作ると、使われなくなったごみデータ（ガベージ）が発生する。

たとえば、次のようなクラスがあると仮定する。

class TreeNode {
    public TreeNode left, right;
    public int data;
    TreeNode(TreeNode l, TreeNode r, int d) {
        left = l; right = r; data = d;
    }
    public void setLeft(TreeNode l) { left = l;}
    public void setRight(TreeNode r) {right = r;}
}

次の処理によって TreeNode を作成する。

TreeNode left = new TreeNode(null, null, 13);
TreeNode right = new TreeNode(null, null, 19);
TreeNode root = new TreeNode(left, right, 17);

このようにすると、ルートノードが left ノードと right ノードを参照する。

ここで right ノードを変更する処理を追加したと仮定する。

root.setRight(new TreeNode(null, null, 21));

すると、もともと right ノードに入っていた 19 番ノードは誰からも参照されなくなり、下図のような状態になる。

この状態では、data=19 の TreeNode インスタンスはどこからも参照されないオブジェクト、つまり到達不能状態のオブジェクト（Unreachable object）となるため、ガベージになる。

これ以上使用されないデータが発生し続けると、不要なメモリが蓄積し、やがて容量の限界に達する。これを未然に防ぐため、ヒープ領域の不要なメモリを自動的に解放する仕組みとして GC（ガベージコレクション）が必要になった。

GC およびヒープ領域の役割

前述のとおり、GC はこれ以上必要のないメモリを解放するメカニズムである。
メモリ内のデータを調べ、参照があれば有効なデータとして残り、参照がなければ不要と判断して解放する。ただし、単純にすべてのメモリ空間を調べると効率が悪いため、データの存在期間に応じて内部的に分けて管理される。

新しいデータは Young Generation、古いデータは Old Generation、事前に変更されにくいと判断されるデータは Permanent Generation と呼ばれる。

基本的にメモリへの割り当ては頻繁に発生するが、そのほとんどは参照されなくなると仮定し、短命なデータ（Young Generation）と長期間参照されるデータ（Old Generation）に分けている。これにより、Young Generation に含まれるデータだけを GC 対象として効率的に確認できる。

また Permanent Generation という領域も存在し、ここにはロードされたクラスの情報など、ある程度変化しないことが保証されるデータが保存される。

Permanent Generation メモリ領域は Java 8 が登場してなくなり、Metaspace 領域が作られた。Metaspace 領域についての詳しい内容はこちらを参考にしてほしい。

参考: OpenJDK ドキュメント

GC サイクル

アプリケーションで使用するヒープ領域は、GC 実行領域別に大きく Young（Eden, Survivor1, Survivor2）領域と Old（Tenured）領域に分けられる。

ヒープ領域の Young 領域は下図のように Eden と Survivor に分かれており、それぞれの領域を使って GC が行われる。

各領域の役割は次のとおりである。

Eden
- Java オブジェクトが生成されるとすぐに割り当てられるメモリ領域である。
- 定期的なガベージコレクションによって生き残ったオブジェクトは Survivor へ移動する。
Survivor1, Survivor2
- GC 後に解放されず、Old には行かないデータ（便宜上 2 つあり、1 と 2 を付けているだけである）
Tenured
- 指定された回数の GC を経て生き残ったデータが Old へ移動される。

GC が実行される領域に応じて、Minor GC と Major GC（Full GC）に分けられる。

Young 領域の GC を Minor GC という。
Old 領域の GC は Full GC（または Major GC）という。

Full GC が発生すると、瞬間的に Java アプリケーションの動作が中断される stop-the-world が発生するため、比較的遅く、性能と安定性に大きな影響を与える可能性がある。

STW(Stop the world)

Stop the world とは、GC がこれ以上必要のないオブジェクトを探して削除するために、GC を実行するスレッド以外の残りのスレッドが停止することを意味する。stop-the-world が発生すると、GC を実行するスレッド以外のすべてのスレッドは作業を停止する。そして GC 作業が完了した後に処理を再開する。STW が発生している間はアプリケーションが停止するため、障害につながる可能性がある。一般に GC チューニングとは、stop-the-world 時間を減らすことである。

Minor GC

Young Generation のみを対象にした GC を Minor GC という。次の特徴がある。

処理時間が短い。
Eden がいっぱいになると発生する。
一定回数 GC 対象になると Old へ移動する。
GC 中はプロセス処理が停止する（Stop the world）。

文章より図で説明するほうが分かりやすいため、図で説明する。

新しくメモリが割り当てられて Eden 領域がいっぱいになると、Minor GC が発生する。
参照がないデータは削除されるが、有効なデータは Survivor 領域にコピーされる。そして Eden 領域はすべて空になる。

その後、この状態で再び Eden 領域がいっぱいになると、再び Minor GC が発生して下図のようになる。

今回は GC 後にすべて Survivor2 領域に入った。Survivor 領域は、どちらか空いている側にデータがコピーされ、1 と 2 を行き来する。そのため、常に Survivor1 と Survivor2 のどちらか一方は空の状態に保たれる。
また、Eden 領域と同様に、Survivor 領域で参照されないデータは削除される。

次は Old 領域への昇格である。GC が発生するたびに Young 領域のデータにはその回数が記録され、一定回数を超えると Old へ移動する。

このように複数回 GC を繰り返すと、Young 領域から Old 領域への移動が発生する。この回数はオプションで指定でき、Old 領域へ行く頻度を次のオプションで制御できる。

-XX:MaxTenuringThreshold=N

Full GC

Young 領域から Old 領域へデータが移る仕組みについて見てきた。これだけであれば Old 領域の容量は常に増え続け、いつか容量の限界に達する。そのため、このとき Full GC が発生する。Old 領域への割り当てに失敗した時点で Full GC が発生し、Old 領域と Young 領域の両方を含めてメモリを清掃する。

これにより、Old 領域でこれ以上必要のない空間を確保し、Survivor 領域にあったデータをコピーできるようになる。

Minor GC と同様に、Full GC 中にもアプリケーションは停止する。そして Old 領域に入っている分だけ停止時間も長くなるため、メモリはできるだけ Young 領域で解放されるようにし、Full GC の発生を最小化することが重要である。

GC サイクルのまとめ

GC サイクルをまとめると次のとおりである。

Eden 領域がいっぱいになると Minor GC が発生する。
Minor GC によって Young 領域を解放し、条件を満たすと Old へ昇格される。
Old 領域がいっぱいになると Full GC が発生する。
Full GC で Old 領域を解放し、昇格できる空間を確保する。

Automatic Garbage Collection

ガベージコレクションの過程について見てみよう。

Automatic Garbage Collection は、ヒープメモリ内でどのオブジェクトが使用中で、どのオブジェクトがそうでないかを判定し、使用されていないオブジェクトを削除する過程である。使用中または参照されているオブジェクトとは、プログラムのどこかがまだそのオブジェクトへのポインタを保持しているという意味である。

C 言語のようなプログラミング言語ではメモリを手動で割り当てたり解放したりしなければならないが、Java では Garbage Collector によって自動的にメモリが解放される。Automatic GC の基本的な過程を見てみよう。

Step 1: Marking

Marking はメモリを断片単位で識別する過程である。

ガベージコレクタは、メモリで参照されているオブジェクト（reachable/live object）を確認し、参照されていないオブジェクト（unreachable object）が何かをマーキングする手順を行う。

参照されるオブジェクトは青色で、残りはオレンジ色で示している。すべてのオブジェクトは、マーキング過程で判定するためにスキャンされる。この過程はシステム内のすべてのオブジェクトをスキャンする必要があるため、時間がかかる。

Step 2: Normal Deletion

Normal Deletion は、参照されていないオブジェクトを削除する過程である。

ガベージコレクタは、参照されていないオブジェクト（unreachable object）を削除する。

参照されていないオブジェクトを削除し、参照されるオブジェクトと free space へのポインタ位置を残す。Memory allocator は、新しく割り当てられるオブジェクトのために free space への参照を保持する。

Step 2a: Deletion with Compacting

Deletion の性能を向上させるため、参照されていないオブジェクトを削除するだけでなく、残った空間を圧縮する過程である。

ガベージコレクタの一部は、memory をより効果的に使用するため、参照されていないオブジェクト（unreachable object）を削除すると同時に圧縮を行うこともある。

オブジェクトを 1 か所に集めることで、新しいメモリ割り当てをより簡単かつ高速にできる。Memory Allocator は free space の開始アドレスだけを持っていればよい。その後、新しいオブジェクトを順次割り当てる。

出典: Oracle 公式ドキュメント: Java Garbage Collection Basics

GC アルゴリズム

GC アルゴリズムはいくつかあり、代表的な次の 4 つについて見ていく。

Serial GC
Parallel GC
CMS (Concurrent Mark & Sweep) GC
ガベージファースト GC(G1GC)

GC アルゴリズムは、スループット（throughput、処理量）と応答時間（Responsiveness: 敏感度）を考慮して分類される。

アプリケーション停止型
- Serial GC, Parallel GC
- シングルコア、マルチコアの基本 GC
- 処理量を重視するが、GC で停止する時間が長くなるため、応答時間の要件を満たせないことがある。
アプリケーションと並行して同時処理する型
- CMS, G1GC
- マルチコア環境で Parallel GC が応答時間要件を満たせない場合に選択
- 処理量が低下する可能性がある。

GC を 2 段階に分け、最大アプリケーション停止を抑制する方法がある。

アプリケーションと同時に GC を実行する段階
アプリケーションを停止して GC を実行する段階

Serial GC

Serial GC は、“Serial” という単語から分かるように「順次的な」GC 方式である。
Java SE 5、6 でのデフォルトガベージコレクタであり、主に 32 ビット JVM でシングルスレッドとして動作する。
シングルスレッドでマーク＆スイープとコンパクション（Mark-Sweep-Compaction）が実行される。
シングルコア環境で利用されていた。

下の画像から分かるように、GC Thread がシングルスレッドで GC を実行するため、実行時間が長い。

つまり、GC Thread の実行中に Stop-the-World（Pause）が発生する時間が長いことを意味する。

Serial GC 関連オプションは次のとおりである。

-XX:+UseSerialGC

Mark-Sweep-Compaction

マーク＆スイープとコンパクション（Mark-Sweep-Compaction）は、さまざまな GC で使用されるアルゴリズムである。基本的な GC 過程と考えるとよい。 GC は使用されないオブジェクトをメモリから削除する処理であるため、GC 対象オブジェクトを識別して削除し、オブジェクトが削除されて断片化したメモリ領域を前方から埋めていく作業を行う。 - 使用されていないオブジェクトを識別する作業（Mark） - 使用されていないオブジェクトを削除する作業（Sweep） - 断片化したメモリ領域を前方から埋める作業（Compaction） Compaction 作業は、Windows のディスクデフラグを思い浮かべると理解しやすい。

Parallel GC

Parallel GC は Serial GC と同じ原理で動作するが、Young 領域の GC 過程をマルチスレッドで実行する点が異なる。
そのため、GC Thread の実行は Serial GC より比較的短く、Stop-the-World（Pause）も短く発生する。

スレッド数を指定し、複数のスレッドを同時に利用して GC を実行する方式で、高速に動作する。
マルチコア環境ではデフォルトであり、マルチスレッドでマーク＆スイープとコンパクションを実施する。

Low-pause 方式と Throughput 方式がある。

Low-pause: GC を速く実行するよりも、瞬間的にアプリケーションの動作が中断される現象（pause）を最小化することに焦点を当てた方式である。
Throughput: Minor GC の迅速な実行に焦点を当てた方式で、Full GC では Mark & Compact アルゴリズムのみを使用する。

Parallel GC 関連オプションは次のとおりである。

-XX:+UseParallelGC
- この CLI オプションを使用すると、マルチスレッド young generation collector とシングルスレッド old generation collector を使用できる。
-XX:ParallelGCThreads=<desired number>
- デフォルトでは、N 個の CPU を使用するホストでは parallel GC が N 個の GC スレッドを使用する。そして使用スレッド数は CLI で制御できる。

Parallel Old GC(Parallel Compacting GC)

Parallel Old GC は Java 5 update 6 から提供された GC 方式である。前述の Parallel GC と比較すると、Old 領域の GC アルゴリズムだけが異なる。この方式は Mark-Summary-Compaction 段階を経る。
Summary 段階は、GC を実行した領域について別途生きているオブジェクトを識別する点で Mark-Sweep-Compaction アルゴリズムの Sweep 段階と異なり、やや複雑な段階を経る。

Parallel Old GC 関連オプションは次のとおりである。

-XX:+UseParallelOldGC
- この CLI オプションを使用すると、young generation と old generation の両方でマルチスレッド collector を使用できる。さらに compacting collector もマルチスレッドで動作する。

CMS (Concurrent Mark & Sweep, 並行マーク＆スイープ) GC

CMS GC は、GC 作業をアプリケーションのスレッドと同時に実行し、GC によるアプリケーション停止（stop-the-world）を最小化することを目的とする。ただし Compacting を実行しないため、memory をより多く消費する。

スレッド間の協調処理などに CPU リソースを使用するため、アプリケーションの処理量（throughput）低下が予想されるが、アプリケーション全体の停止時間は短くなる。その結果、GC が応答時間に与える影響は小さくなる。

CPU 使用率が高い場合に性能が低下することがあり、その場合は Parallel GC を使用する。
短所としては、CPU リソースを多く使用し、メモリ断片化が発生する可能性がある。

Initial Mark 段階で参照状態のオブジェクトを短時間で Marking した後、全停止なしに Concurrent Mark 段階で参照状態のオブジェクトを確認する。
Remark 段階で変更または追加されたオブジェクトを確認する。Concurrent Sweep 段階で参照されていないオブジェクトを整理する。

CMS GC 関連オプションは次のとおりである。

-XX:+UseConcMarkSweepGC

G1(Garbage First) GC

G1 GC は CMS を置き換えるために作られた。従来の Young、Old という領域には分けられず、ヒープを “Region” と呼ばれる小さな領域に分けて管理する。1 つ以上の Region からオブジェクトをコピーして別の Region へ移動する方式である。CMS と異なり、Compaction 段階によってメモリ断片化をなくした。Java 7 で正式に追加された。

複数 CPU と非常に大きな memory で効果的な GC を活用するためのものだ。Oracle ドキュメントによれば、heap size が 6GB より大きい場合、GC のレイテンシ（latency）を 0.5sec 以下に下げられるという。Oracle G1 GC ドキュメントによれば、Java 9 では default GC に設定されている。（それまでは Parallel GC が default）

G1 GC は Garbage だけがある Region を最初に回収するため、Garbage First という名前が付けられた。

G1 GC 関連オプションは次のとおりである。

-XX:+UseG1GC

GC の歴史

Java 6 以前
- Serial GC, Parallel GC, CMS GC
Java 8
- Serial GC, Parallel GC がデフォルト
Java 7
- G1 GC が追加
Java 9
- G1 GC がデフォルト

参考

Java String 定数プール

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

String がメモリに保存される方式

Java で String を生成する方法は 2 つある。

new 演算子を使う方式
リテラル(Literal)を使う方式

2 つの宣言方式の違いは次のとおりである。

	`new` 宣言	リテラル宣言
保存場所	“Heap” 領域に保存	“String constant pool” に保存
速度	Literal 宣言より遅い	`new` 宣言より速い
同じ文字列の比較	`.equals` メソッドで比較すると同じ結果になる	`==` 演算子で比較できる

“String constant pool” に文字列が存在すればそのアドレス値を返し、存在しなければ新しく保存して新しいアドレス値を返す。 string constant pool は Perm 領域に存在していたが、Java 7 を境に位置が変更された。

同じ文字列を上記 2 つの方式で生成し、== 演算子と .equals() で比較すると、次のような結果になる。

public static void main(String[] args) {
    String a = "apple";
    String b = "apple";
    String c = new String("apple");
    
    System.out.println(a == b); // true
    System.out.println(a == c); // false
    
    System.out.println(a.equals(b)); // true
    System.out.println(a.equals(c)); // true
}

String constant pool の位置変更

Java 6 まで String constant pool の位置は Perm 領域だった。Perm 領域にあったものが Java 7 で Heap 領域に変更された。その理由は OutOfMemoryException の問題である。

Perm 領域は固定サイズであり、Runtime にサイズが拡張されない。Perm 領域のサイズを増やすことはできるが、いずれにしても Runtime にサイズが変わるわけではない。そのため Java 6 までは、String の intern() メソッドを呼び出すと OutOfMemoryException が発生する可能性があり、その部分を制御できなかったため、ほとんど使用しないのが妥当だった。

そこで Oracle のエンジニアは、Java 7 で string constant pool の位置を Perm 領域ではなく Heap 領域へ変更した。Heap 領域へ変更することで得られる利点は何だろうか。それは、string constant pool のすべての文字列も GC の対象になれるという点である。

String constant pool のサイズは -xx:StringTableSize オプションで指定できる。ここには 1,000,000 のような数字ではなく、1,000,003 のような素数を使う必要がある。これは hashCode 性能に関係する部分であり、Java Performance Tuning Guide の記事に詳しい内容がある。

intern() メソッドを積極的に使うなら、-xx:StringTableSize のデフォルト値（1009）より高く設定する必要がある。そうしないと、Linked List レベルの性能に低下するとされている。

参考

Java String のメモリに関する考察

Java ClassLoader

kc@example.com (kc kim) — Sat, 09 Dec 2023 23:56:00 +0900

ClassLoader とは

JVM はクラスをロードするために Class Loader と呼ばれるものを使用している。 Class Loader は 1 つだけではなく、JVM が用途別に複数のクラスローダーを使うほか、J2EE コンテナでは複数のクラスローダーが階層的に追加定義されており、ユーザーが独自に定義することも可能である。

Class Loader はクラスをメモリ上にロードする。言い換えると、コンパイルされたクラス（.class）を動的にメモリへロードする役割を持つ。ここで動的にロードするとは、コンパイル時ではなく実行時にクラスファイルが必要になって実行する場合に、メモリへ載せるという意味である。

ClassLoader の基本動作

J2SE に定義されたクラスローダーは次の 3 つである。

ブートストラップクラスローダー（Bootstrap Class Loader）
- 初期クラスローダー
- コアパッケージなど（rt.jar、i18n.jar）のクラスローダー
拡張クラスローダー（Extension Class Loader）
- 拡張機能のインストール型オプションパッケージ（lib/ext）のクラスローダー
- Java 8 まで: URLClassLoader を継承し、jre/lib/ext および java.ext.dirs 環境変数で指定されたフォルダ内のクラスをロードする。
- Java 9 以降: jre/lib/ext と java.ext.dirs をサポートせず、Java SE のすべてのクラスと JCP（Java Community Process）によって標準化されたモジュールのクラスをロードする。
  - BuiltinClassLoader を継承して ClassLoader の内部 static クラスとして実装され、PlatformClassLoader に変更された。
ユーザー定義クラスローダー（System Class Loader、Application Class Loader）
- classpath クラスローダー

クラスローダー間には親子関係があり、親クラスローダーは子クラスローダーを知らないが、子クラスローダーは親を知っている。子クラスローダーにクラスロード要求が入ると、親に委譲して最初に見つかったクラスをロードする。もし対象クラスが、要求を受けたクラスローダーより子クラスローダーの責任範囲にあるなら、そのクラスは見つからずロードに失敗する。

クラスローダーがクラスロードを要求される。loadClass()
すでにロードされているか確認する。findLoadedClass
ロードされていなければ、親クラスローダー（ない場合はブートストラップクラスローダー findBootstrapClassOrNull()）へ処理を委譲（delegation）する。parent.loadClass(name, false)
ロードされなければ探してロードを試みる。findClass()

具体的には java.lang.ClassLoader の loadClass(..) メソッドを見ると、上記の内容を確認できる。

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

ブートストラップクラスローダーはコアパッケージなどをロードするクラスローダーであり、それ自体は親を持たない。ユーザー定義クラスローダーは、起動時に実行されるシステムクラスローダーを親として派生する。

たとえば J2EE コンテナの場合、EAR のユーティリティ JAR をロードするクラスローダーは、WAR の Web コンポーネントをロードするクラスローダーの親になるため、Web コンポーネントは EAR のユーティリティ JAR を呼び出せる。逆に、EAR のユーティリティ JAR は子である WAR 内の Web コンポーネントを呼び出せない。

また、static で限定されたフィールドはクラスロード時に一度だけ実行されるため、クラスローダー内で 1 つになる。クラスローダーを統合すればユーティリティクラスを共通クラスにできるが、予期しない副作用が発生する可能性があるため、動作を理解してよく確認する必要がある。

クラスローダーは抽象クラス java.lang.ClassLoader を継承したクラスである。たとえば、コアパッケージ内では java.security.SecureClassLoader や java.net.URLClassLoader がこのクラスを継承したクラスとして定義されている。

ClassLoader を検索する例

次のコードは、クラスローダーを検索する例である。

package com.devkuma.basic.classloader;

class GetClassLoader {
    public static void main(String[] args) {
        // Bootstrap class loader
        System.out.println("- Bootstrap Class Loader");
        ClassLoader bootstrap = "".getClass().getClassLoader();
        System.out.println(bootstrap);
        if (bootstrap != null) {
            ClassLoader parent = bootstrap.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }

        // Platform Class Loader
        System.out.println("- Platform Class Loader");
        ClassLoader extensions = GetClassLoader.class.getClassLoader().getParent();
        System.out.println(extensions);
        if (extensions != null) {
            ClassLoader parent = extensions.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }

        // System Class Loader
        System.out.println("- System Class Loader");
        DemoClass myObj = new DemoClass();
        ClassLoader systems = myObj.getClass().getClassLoader();
        System.out.println(systems);
        if (systems != null) {
            ClassLoader parent = systems.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }

        // Context Classloader
        System.out.println("- Context Classloader");
        ClassLoader threads = Thread.currentThread().getContextClassLoader();
        System.out.println(threads);
        if (threads != null) {
            ClassLoader parent = threads.getParent();
            System.out.println(parent);
        } else {
            System.out.println("No parent");
        }
    }
}

class DemoClass {
    String getClassName() {
        return "DemoClass";
    }
}

次のように出力される。ここでコンテキストクラスローダーは、そのスレッド内でクラスをロードするために使用されるクラスローダーである。

- Bootstrap Class Loader
null
No parent
- Platform Class Loader
jdk.internal.loader.ClassLoaders$PlatformClassLoader@7dc5e7b4
null
- System Class Loader
jdk.internal.loader.ClassLoaders$AppClassLoader@799f7e29
jdk.internal.loader.ClassLoaders$PlatformClassLoader@7dc5e7b4
- Context Classloader
jdk.internal.loader.ClassLoaders$AppClassLoader@799f7e29
jdk.internal.loader.ClassLoaders$PlatformClassLoader@7dc5e7b4

JVM メモリ

kc@example.com (kc kim) — Thu, 20 Jan 2022 07:48:00 +0900

JVM (Java Virtual Machine)

Java バイトコードを機械語として使用するコンピュータを Java 仮想マシンという。