java.lang.OutOfMemoryError: Java heap spaceの原因と解消法｜メモリ調整と調査手順

2026年3月15日2026年5月5日

例外処理・デバッグ

Javaアプリケーションの開発や運用において、最も遭遇頻度が高く、かつエンジニアを悩ませるトラブルの一つが java.lang.OutOfMemoryError: Java heap space です。

このエラーは、Java仮想マシン (JVM) が新しいオブジェクトを割り当てるためのメモリ領域を確保できず、かつガベージコレクション (GC) によっても空き容量を増やせない状態に陥ったことを示しています。

システムの停止やレスポンス遅延に直結するため、迅速な原因究明と適切な対策が求められます。

本記事では、このエラーが発生するメカニズムから、主な原因、具体的な調査手順、そして根本的な解消法までを専門的な視点で詳しく解説します。

目次 [ close ]

Java Heap Spaceエラーが発生する仕組み

Javaのメモリ管理は、JVMによって自動的に行われますが、その中でも「ヒープ領域 (Heap Area)」はアプリケーションが動的に生成するオブジェクトが格納される主要な場所です。

JVMメモリ構造とヒープの役割

JVMのメモリ領域は、大きく分けて「ヒープ領域」と「メタスペース (非ヒープ領域)」、「スタック領域」などに分類されます。

Java heap spaceエラーは、このうちヒープ領域が不足していることを指します。

ヒープ領域はさらに、短命なオブジェクトを管理する「Young Generation (若年世代)」と、長期間生存するオブジェクトが移動する「Old Generation (老齢世代)」に分かれています。

通常の運用では、ガベージコレクションが不要になったオブジェクトを回収し、領域を解放しますが、解放される量よりも生成される量が多い場合や、どこからも参照されていないはずのオブジェクトがメモリに残り続ける場合に、最終的にこのエラーがスローされます。

エラーがスローされるタイミング

JVMはメモリが不足すると、必死にガベージコレクションを繰り返して空きを作ろうと試みます。

しかし、GCを実行してもメモリの空きがわずかしか増えず、かつアプリケーションが要求するメモリ量を満たせない場合、JVMはこれ以上の実行は不可能と判断し、java.lang.OutOfMemoryError を発生させてプロセスを停止、あるいはスレッドを異常終了させます。

主な原因の切り分け

このエラーが発生する原因は多岐にわたりますが、大きく分けると「設定不足」「実装上の不備」「想定外の負荷」の3つに分類できます。

1. JVMヒープサイズの設定不足

最も単純な原因は、アプリケーションが必要とするメモリ量に対して、JVMに割り当てられた最大ヒープサイズ (-Xmx) が小さすぎるケースです。

Javaのデフォルトのヒープサイズは、実行環境の物理メモリ量に基づいて自動的に決定されますが、大規模なデータを扱うアプリケーションや、多くのライブラリをロードするマイクロサービスでは、デフォルト値では不足することが多々あります。

2. メモリリーク (Memory Leak)

プログラムの実装ミスにより、不要になったオブジェクトがいつまでも参照され続け、GCの対象にならない現象です。

Javaは自動メモリ管理を行いますが、静的変数 (static) や長寿命なコレクションクラス (HashMapやList) にオブジェクトを格納したまま削除し忘れると、それらは「ルートからの参照」があるため破棄されません。

これが蓄積されると、最終的にヒープ領域を使い果たします。

3. 一時的なデータ処理量の増大

バッチ処理などで一度に数百万件のデータをデータベースから読み込んだり、巨大なファイルをメモリ上で展開しようとしたりする場合に発生します。

「普段は正常に動いているが、特定の重い処理を実行したときだけ落ちる」という場合は、このケースが疑われます。

4. 過度なファイナライザの利用

finalize() メソッドを実装しているクラスが多い場合、オブジェクトの回収が遅れることがあります。

Java 9以降、ファイナライザは非推奨となっていますが、古いライブラリやレガシーコードを利用している場合に、GCの効率を著しく低下させる要因となります。

メモリ調整による即時対応

エラーが発生した際の応急処置として、まずはJVMのメモリ割り当てを調整することが一般的です。

JVMオプションの変更

Javaの起動オプションを指定することで、ヒープ領域のサイズを明示的に拡大できます。

オプション	内容
`-Xms`	ヒープ領域の初期サイズを指定します。
`-Xmx`	ヒープ領域の最大サイズを指定します。
`-XX:MaxMetaspaceSize`	クラスメタデータなどを保持する領域の最大値を指定します。

例えば、最大ヒープサイズを4GBに設定する場合は以下のように記述します。

Shell

java -Xms2g -Xmx4g -jar your-application.jar

初期サイズ (-Xms) と最大サイズ (-Xmx) を同じ値に設定することで、実行中のヒープ拡張によるオーバーヘッドを減らし、パフォーマンスを安定させる手法も広く使われています。

メモリリークの調査手順

メモリサイズを増やしてもエラーが再発する場合、根本的な原因であるメモリリークを特定する必要があります。

以下の手順で詳細な分析を行います。

1. ヒープダンプの取得

メモリリークを特定するための最も確実な方法は、エラー発生時のメモリの状態を丸ごと書き出した「ヒープダンプ (.hprofファイル)」を解析することです。

以下のJVMオプションを付与しておくことで、OutOfMemoryErrorが発生した瞬間に自動でダンプを出力させることが可能です。

Shell

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./logs/heapdump.hprof

手動で取得する場合は、JDKに標準搭載されている jmap コマンドを使用します。

Shell

jmap -dump:format=b,file=heapdump.hprof <PID>

2. 解析ツールの活用

取得したヒープダンプはバイナリ形式であるため、専用の解析ツールを使用して可視化します。

Eclipse Memory Analyzer (MAT): 最も強力なオープンソースツールです。「Leak Suspects」レポート機能により、どのオブジェクトがメモリを占有しているかを自動で推論してくれます。
VisualVM: JDKに付属（または別途ダウンロード）するGUIツールで、リアルタイムのメモリ推移やダンプの簡易解析が可能です。
JProfiler / YourKit: 有償ですが、非常に高度なプロファイリングが可能です。

3. オブジェクトの参照ツリーを確認

解析ツール上では「Dominator Tree (支配ツリー)」を確認します。

これにより、どの大きなオブジェクトが他のどのオブジェクトを保持しているかが一目でわかります。

例えば、特定の ArrayList が数ギガバイトのメモリを保持しており、その中身が古いセッションデータであれば、セッション破棄のロジックに不備があることが特定できます。

原因特定のためのサンプルコードと実行結果

意図的にメモリリークを発生させるコード例を確認し、どのようにエラーが表現されるかを把握しましょう。

Java

import java.util.ArrayList;
import java.util.List;

/**
 メモリリークをシミュレートするクラス
 */
public class MemoryLeakDemo {
    // 静的リストにデータを追加し続けることで、GCの対象から外す
    private static final List<byte[]> leakList = new ArrayList<>();

    public static void main(String[] args) {
        System.out.println("Starting memory leak simulation...");

        try {
            while (true) {
                // 1MBのバイト配列を生成してリストに追加
                byte[] data = new byte[1024 * 1024];
                leakList.add(data);

                // 現在のメモリ使用状況を表示
                long freeMemory = Runtime.getRuntime().freeMemory() / 1024 / 1024;
                System.out.println("Free memory: " + freeMemory + " MB");
                
                // 処理を少し待機（急激なクラッシュを避けるため）
                Thread.sleep(10);
            }
        } catch (OutOfMemoryError e) {
            // エラーをキャッチしてメッセージを表示
            System.err.println("CRITICAL ERROR: " + e.getMessage());
            e.printStackTrace();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

このプログラムを実行すると、ヒープ領域が徐々に圧迫され、最終的に以下の出力を伴って停止します。

実行結果

Starting memory leak simulation...
Free memory: 240 MB
Free memory: 239 MB
...
Free memory: 5 MB
CRITICAL ERROR: Java heap space
java.lang.OutOfMemoryError: Java heap space
    at MemoryLeakDemo.main(MemoryLeakDemo.java:16)

この例では、static 修飾子が付いた leakList がルート参照を持ち続けているため、配列データが一度も解放されることなく蓄積されたことが原因です。

実装レベルでの解消法とベストプラクティス

調査によって原因が判明した後は、コードの修正やアーキテクチャの改善を行います。

コレクションの適切な管理

リストやマップにオブジェクトを追加する場合、必ず「いつ削除されるか」を設計に含めてください。

特にキャッシュ機能を独自に実装する場合は、WeakHashMap を検討するか、GuavaやCaffeineといったライブラリを使用して、サイズ制限や有効期限 (TTL) を設けることが推奨されます。

ストリーム処理の活用

巨大なファイルを扱う際、ファイルを一度にメモリへ読み込む Files.readAllBytes() などの使用は避けるべきです。

代わりに、InputStream や BufferedReader を用いて、1行ずつ、あるいはバッファ単位で処理を行うように変更します。

データベース接続とリソースのクローズ

データベースから大量のレコードを取得する際は、フェッチサイズを適切に設定し、カーソルを用いて少しずつデータを処理するようにします。

また、try-with-resources文 を確実に使用し、リソースのクローズ漏れを防ぐことも基本ですが非常に重要です。

ガベージコレクションアルゴリズムの選定

最新のJava（JDK 17や21など）を使用している場合、デフォルトの G1GC (Garbage First Garbage Collector) は非常に優秀ですが、より低遅延や大容量メモリを求める場合は ZGC や Shenandoah への変更を検討してください。

これらは、ヒープが巨大になっても停止時間 (Stop The World) を極小に抑える工夫がなされています。

まとめ

java.lang.OutOfMemoryError: Java heap space は、単なるメモリ不足ではなく、アプリケーションの設計や実装上の課題を映し出す鏡のようなエラーです。

まずは -Xmx による割り当てサイズの調整で状況が改善するかを確認し、それでも解消しない場合はヒープダンプを取得して詳細な分析を行ってください。

「どこでオブジェクトが作られ、なぜ解放されないのか」を論理的に突き止めることが、根本解決への唯一の近道です。

最新のプロファイリングツールやJVMの機能を活用し、メモリ効率の高い堅牢なアプリケーション構築を目指しましょう。

日頃からのモニタリングと、負荷試験による限界値の把握が、本番環境でのトラブルを未然に防ぐ鍵となります。