Java | Java 詳細・モダン文法：JVM・パフォーマンス – JVM メモリ構造

JVM メモリ構造をざっくり一枚の絵にする
ヒープ（Heap）：new したものが全部集まる「オブジェクトの街」
スタック（Stack）：メソッド呼び出しの「作業台」
メソッド領域／メタスペース：クラスの「設計図置き場」
1. 何が置かれる場所か
2. なぜここを意識する必要があるのか
簡単なコードで「どこに何が置かれるか」を追ってみる
パフォーマンスの観点から見た JVM メモリ構造のポイント
まとめ：JVM メモリ構造を自分の言葉で説明するなら

JVM メモリ構造をざっくり一枚の絵にする

まずイメージからいきます。
JVM のメモリは、大きく言うと次のような「部屋」に分かれています。

ヒープ（Heap）：new したオブジェクトが住む場所
スタック（Stack）：メソッド呼び出しの一時的な作業台
メソッド領域／メタスペース：クラスやメソッドの情報が置かれる場所
そのほか、スレッドごとの小さな領域やネイティブコード用の領域

この「部屋の役割」が分かると、
「なぜ GC が必要なのか」「なぜスタックオーバーフローが起きるのか」
といった話が一気につながります。

ヒープ（Heap）：new したものが全部集まる「オブジェクトの街」

何が置かれる場所か

ヒープは、new したオブジェクトや配列が置かれる場所です。
new String("hello") も、new int[10] も、new ArrayList<>() も、全部ヒープに置かれます。

Java の「参照型」は、基本的にここに住みます。
変数が持っているのは「ヒープ上のオブジェクトへの参照（住所）」です。

String s = new String("hello");

String s = new String("hello");

Java

このとき、
s という変数はスタックに置かれ、
実体の "hello" オブジェクトはヒープに置かれます。

ヒープはなぜ GC とセットなのか

ヒープに置かれたオブジェクトは、
「もうどこからも参照されなくなったら、GC が回収してくれる」
というルールで管理されています。

だから Java では、C のように free や delete を書かなくていい。
代わりに、ヒープは「GC が掃除する前提でどんどん散らかる場所」だと思ってください。

ヒープの中の「世代」：Young / Old

実際の JVM では、ヒープはさらに「世代」に分かれます。

Young（若い世代）：生まれたばかりのオブジェクト
Old（年老いた世代）：長生きしているオブジェクト

多くのオブジェクトは「すぐ死ぬ（すぐ使われなくなる）」という経験則があるので、
Young 領域は「頻繁に、素早く GC する」ように設計されています。

Young で何回か GC を生き延びたオブジェクトは、Old に昇格します。
Old は「長生き組」なので、GC の頻度は低いけれど、一回の GC は重めです。

この「世代別 GC」の仕組みが、Java のパフォーマンスチューニングの土台になります。

スタック（Stack）：メソッド呼び出しの「作業台」

スレッドごとに一つずつある

スタックは「スレッドごと」に用意されます。
スレッドが一つ増えると、そのスレッド専用のスタックが一つ増えます。

スタックには、メソッド呼び出しごとに「スタックフレーム」と呼ばれる枠が積み上がります。

void a() {
    int x = 10;
    b(x);
}

void b(int y) {
    int z = y + 1;
}

void a() {
    int x = 10;
    b(x);
}

void b(int y) {
    int z = y + 1;
}

Java

a() を呼ぶとき、a 用のフレームがスタックに積まれ、
その中にローカル変数 x や引数などが置かれます。

a の中から b を呼ぶと、b 用のフレームがその上に積まれ、
y や z がそこに置かれます。

メソッドが終わると、そのフレームはスタックからポンと外されます。
だから、スタック上のデータは「メソッドの寿命と一緒」です。

スタックに置かれるもの・置かれないもの

スタックに置かれるのは、主に次のようなものです。

プリミティブ型のローカル変数（int, long, double など）
参照型の「参照（ポインタ）」
戻り先アドレスや一時的な計算用の値

new したオブジェクトの「中身」はスタックには置かれません。
スタックにあるのは「そのオブジェクトへの参照」だけです。

スタックオーバーフローはなぜ起きるのか

スタックはサイズに上限があります。
再帰呼び出しを深くしすぎると、フレームが積み上がりすぎて、
スタックの上限を超えます。

void recurse() {
    recurse();
}

void recurse() {
    recurse();
}

Java

これを呼ぶと、延々とフレームが積まれていき、
StackOverflowError が発生します。

「スタックはメソッド呼び出しのための有限の積み重ねスペース」
というイメージを持っておくと、このエラーの意味が腑に落ちます。

メソッド領域／メタスペース：クラスの「設計図置き場」

何が置かれる場所か

JVM は、クラスをロードするときに、
そのクラスの「メタ情報（設計図）」を専用の領域に置きます。

そこには、例えばこんな情報が入っています。

クラス名、パッケージ名
フィールドやメソッドの一覧
メソッドのバイトコード
定数プール（リテラル文字列など）

昔の JVM ではこれを「メソッド領域（Method Area）」や「PermGen」と呼んでいましたが、
今の HotSpot JVM では「メタスペース（Metaspace）」という形でネイティブメモリ側に置かれます。

なぜここを意識する必要があるのか

普通のアプリではあまり意識しませんが、
大量のクラスを動的に生成・ロードするようなフレームワーク（JPA、Proxy、動的クラス生成など）を使うと、
この領域がパンパンになって OutOfMemoryError を起こすことがあります。

「オブジェクトが多すぎてヒープが足りない」のとは別に、
「クラスの設計図が多すぎてメタスペースが足りない」というパターンもある、
ということだけ頭の片隅に置いておくと、エラーの意味が読みやすくなります。

簡単なコードで「どこに何が置かれるか」を追ってみる

例コード

public class MemoryExample {
    public static void main(String[] args) {
        int a = 10;
        String s = new String("hello");
        int[] arr = new int[3];
        arr[0] = a;
        print(s, arr);
    }

    static void print(String msg, int[] values) {
        int len = values.length;
        System.out.println(msg + " : " + len);
    }
}

public class MemoryExample {
    public static void main(String[] args) {
        int a = 10;
        String s = new String("hello");
        int[] arr = new int[3];
        arr[0] = a;
        print(s, arr);
    }

    static void print(String msg, int[] values) {
        int len = values.length;
        System.out.println(msg + " : " + len);
    }
}