Java 例外 OutOfMemoryError の解決策-＆＃＆チュートリアル-php.cn

Java 例外 OutOfMemoryError の解決策

不言

リリース： 2019-01-30 11:08:17

転載

3209 人が閲覧しました

この記事の内容は Java 例外 OutOfMemoryError の解決方法です。必要な方は参考にしていただければ幸いです。

Java 仮想マシン仕様の説明では、プログラムカウンターに加えて、仮想マシンメモリの他のいくつかの実行領域でも OOM 例外が発生する可能性があります。ここでは、コードを使用して各ランタイム領域に何が保存されているかを確認し、それを処理する方法について説明します。

Java ヒープオーバーフロー

オブジェクトが継続的に作成され、GC ルートとの間に到達可能なパスがある限り、Java ヒープはオブジェクトインスタンスを格納するために使用されます。ガベージコレクションメカニズムを回避してこれらのオブジェクトをクリアすると、オブジェクト数が最大ヒープ容量制限に達した後にメモリオーバーフロー例外が発生します。

例外の再現

コードでは次の仮想マシンパラメータを使用します:

-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError

ログイン後にコピー

このようにして、Java ヒープのサイズは次のように制限されます。 20MB で拡張できません。パラメータ -XX: HeapDumpOnOutOfMemoryError を使用すると、メモリオーバーフロー例外が発生したときに、仮想マシンが分析のために現在のメモリヒープダンプスナップショットをダンプできるようになります。

次のコードを使用して検証します:

public class HeapOOM {
    static class OOMObject {
    }
    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();

        while (true) {
            list.add(new OOMObject());
        }
    }
}

ログイン後にコピー

実行結果:

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid3460.hprof ...
Heap dump file created [28199779 bytes in 0.237 secs]

ログイン後にコピー

解決策

Java ヒープメモリの OOM 例外は、実際には共通メモリです。アプリケーションオーバーフロー例外が発生すると、多くの場合、「Java ヒープスペース」というプロンプトが表示されます。

この領域の異常を解決するには、まずMATなどのメモリイメージ解析ツールを使用して、メモリリークやメモリオーバーフローが発生していないかを確認するのが一般的な方法です。

メモリリークの場合は、さらにツールを使用してリークしたオブジェクトから GC ルートへの参照チェーンを表示し、リークしたオブジェクトが GC ルートとどのように関連付けられているか、ガベージコレクターによる自動的なリサイクルの防止を確認できます。彼らの空間。

メモリリークではない場合、つまり、メモリ内のオブジェクトが本当に存続する必要がある場合は、仮想マシンのヒープパラメータを確認し、それをマシンの物理メモリと比較する必要があります。増やすことができるかどうかを確認してください。コードの観点から、一部のオブジェクトのライフサイクルが長すぎたり、状態の保持時間が長すぎたりする状況がないかどうかを確認し、プログラムの実行中のメモリ消費量を減らすようにしてください。

仮想マシンスタックとローカルメソッドスタックのオーバーフロー

HotSpot 仮想マシンでは仮想マシンスタックとローカルメソッドスタックが区別されないため、HotSpot では -Xoss パラメータが存在しますが、実際、スタック容量は -Xss パラメータによってのみ設定されます。

例外の再現

シングルスレッドでは、コードは次の仮想マシンパラメータを使用します。

-Xss128k

ログイン後にコピー

このパラメータを使用してスタック容量を削減し、次のコードを使用して再現します。例外:

public class JavaVMStackSOF {

    private int stackLength = 1;

    public void stackLeak() {
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) throws Throwable {
        JavaVMStackSOF oom = new JavaVMStackSOF();
        try {
            oom.stackLeak();
        } catch (Throwable e) {
            System.out.println("stack length:" + oom.stackLength);
            throw e;
        }
    }
}

ログイン後にコピー

Solution

仮想マシンのデフォルトのパラメータを使用する場合、スタックの深さはほとんどの場合異なります (各メソッドによってスタックにプッシュされるフレームサイズが異なるため)同じではないので、ほとんどの場合、1000 ～ 2000 に達しても問題ないとしか言えません。通常のメソッド呼び出し (再帰を含む) では、この深さで完全に十分です。

ただし、スレッドの作成が多すぎるためにメモリオーバーフローが発生し、スレッド数を減らすことができないか、64 ビットの仮想マシンを置き換えることができない場合は、最大ヒープを減らすしか方法がありません。配線の増加と引き換えにスタック容量も増加します。

ネイティブダイレクトメモリオーバーフロー

DirectMemory 容量は -XX: MaxDirectMemorySize で指定できます。指定しない場合、デフォルトはJava の最大ヒープ。

例外の再現

次の仮想マシンパラメータを使用します:

-Xmx20M -XX:MaxDirectMemorySize=10M

ログイン後にコピー

次のコードを使用して例外を再現します:

public class DirectMemoryOOM {
    private static final int _1MB = 1024 * 1024;
    public static void main(String[] args) throws Exception {
        Field unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe) unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB);//直接申请分配内存
        }
    }
}

ログイン後にコピー