JVM 実用的な OutOfMemoryError 例外

[[420231]]

Java 仮想マシン仕様によれば、プログラムカウンタに加えて、仮想マシンメモリの他のいくつかのランタイム領域でも OutOfMemoryError (以下、OOM) 例外が発生する可能性があります。 (この記事は主にjdk1.8に基づいています)

Java ヒープオーバーフロー

Java ヒープはオブジェクトインスタンスを格納するために使用されます。オブジェクトを作成し続け、GC ルートからオブジェクトに到達可能なパスを確保して、ガベージコレクションメカニズムがこれらのオブジェクトをクリアしないようにする限り、オブジェクトの数が増加するにつれて、合計容量が最大ヒープ容量制限に達し、メモリオーバーフロー例外が発生します。

シミュレーションコード

以下はヒープメモリのオーバーフローをシミュレートする簡単なコードです。

 /**
 * VM 引数: -Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError
 * @著者 鄭sh
 * @日付2021-8-13
 */
パブリッククラスHeapOOM { 
     
公共 静的void main(String[] args) {
        リスト<byte[]> リスト = 新しい ArrayList<>();
        （真）の間{
            list.add (新しいバイト[2048]);
        }
    }
 }

返される結果情報は次のとおりです。

スレッド「main」で例外が発生しましたjava.lang.OutOfMemoryError: Java ヒープスペース 
 cn.zhengsh.jvm.oom.HeapOOM.main(HeapOOM.java:16)で

問題分析

メモリリーク（Memory Leak）なのかメモリオーバーフロー（Memory Overflow）なのかを特定する必要があります。

メモリリーク
メモリリーク

メモリリーク

JDK に付属する jvisualvm ツールを使用して、ヒープスナップショットファイルを読み込み、分析することができます。メモリリークの場合は、さらにツールを使用して、リークされたオブジェクトから GC ルートまでの参照チェーンを表示し、リークされたオブジェクトがどの参照パスに関連付けられているか、およびどの GC ルートであるかを調べて、ガベージコレクターによる再利用を防ぐことができます。リークされたオブジェクトの型情報と GC ルートへの参照チェーンに基づいて、通常、これらのオブジェクトが作成される場所をより正確に特定し、メモリリークの原因となるコードの特定の場所を見つけることができます。

メモリリーク

メモリリークではない場合、つまりメモリ内のオブジェクトが実際に存続する必要がある場合は、Java 仮想マシンのヒープパラメータ (-Xmx および -Xms) 設定を確認し、マシンのメモリと比較して、上方調整の余地があるかどうかを確認する必要があります。次に、コードをチェックして、ライフサイクルが長すぎるオブジェクト、保持時間が長すぎるオブジェクト、不合理なストレージ構造設計などがないかどうかを確認し、プログラム実行中のメモリ消費を最小限に抑えます。

仮想マシンスタックとネイティブメソッドスタックオーバーフロー

HotSpot 仮想マシンは、仮想マシンスタックとローカルメソッドスタックを区別しません。したがって、HotSpot の場合、-Xoss パラメータ (ローカルメソッドスタックサイズの設定) が存在しますが、実際には効果はありません。スタック容量は -Xss パラメータでのみ設定できます。仮想マシンスタックとネイティブメソッドスタックに関しては、Java 仮想マシン仕様に次の 2 つの例外が記述されています。

スレッドによって要求されたスタックの深さが仮想マシンで許可される最大深さより大きい場合、StackOverflowError 例外がスローされます。
仮想マシンのスタックメモリが動的拡張を許可している場合、拡張されたスタック容量が十分なメモリに適用できないときに OutOfMemoryError 例外がスローされます。

Java 仮想マシン仕様では、Java 仮想マシン実装がスタックの動的な拡張をサポートするかどうかを選択することが明示的に許可されていますが、HotSpot 仮想マシンは拡張をサポートしないことを選択しています。そのため、スレッド作成時やメモリ申請時にメモリ不足が発生して OutOfMemoryError 例外が発生しない限り、拡張によりスレッド実行時にメモリオーバーフローが発生することはありません。スタック容量が新しいスタックフレームに対応できないため、StackOverflowError 例外が発生するだけです。

仮想マシンのスタックメモリオーバーフロー

スタックオーバーフローエラー

サンプルコード:

 /**
 * VM引数: -Xss128k
 *
 * @著者 鄭sh
 * @日付2021-08-13
 */
パブリッククラスJavaVMStackSOF {
    プライベートintスタック長さ = 1; 
 
パブリックボイドスタックリーク() {
        スタック長++;
        スタックリーク();
    } 
 
公共 静的void main(String[] args) throws Throwable {
        JavaVMStackSOF oom = 新しい JavaVMStackSOF();
        試す {
            oom.stackLeak();
        } キャッチ (Throwable e) {
            システム。 out .println( "スタックの長さ:" + oom.stackLength);
            eを投げる;
        }
    }
 }

例外情報を返します

スレッド「main」で例外が発生しましたjava.lang.StackOverflowError
スタック長:992
 cn.zhengsh.jvm.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:13)で
cn.zhengsh.jvm.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:14)で
  //.... 以下省略

メモリ不足エラー

パッケージ cn.zhengsh.jvm.oom; 
 
 /**
 * @著者 鄭sh
 * @日付2021-08-13
 */
パブリッククラスJavaVMStackSOF2 {
    プライベートスタティック  intスタック長さ = 0; 
 
公共 静的voidテスト（）{
        長い unused1、 unused2、 unused3、 unused4、 unused5、 unused6、 unused7、 unused8、 unused9、 unused10、 unused11、
            未使用12、未使用13、未使用14、未使用15、未使用16、未使用17、未使用18、未使用19、未使用20、未使用21、
            未使用22、未使用23、未使用24、未使用25、未使用26、未使用27、未使用28、未使用29、未使用30、未使用31、
            未使用32、未使用33、未使用34、未使用35、未使用36、未使用37、未使用38、未使用39、未使用40、未使用41、
            未使用42、未使用43、未使用44、未使用45、未使用46、未使用47、未使用48、未使用49、未使用50、未使用51、
            未使用52、未使用53、未使用54、未使用55、未使用56、未使用57、未使用58、未使用59、未使用60、未使用61、
            未使用62、未使用63、未使用64、未使用65、未使用66、未使用67、未使用68、未使用69、未使用70、未使用71、
            未使用72、未使用73、未使用74、未使用75、未使用76、未使用77、未使用78、未使用79、未使用80、未使用81、
            未使用82、未使用83、未使用84、未使用85、未使用86、未使用87、未使用88、未使用89、未使用90、未使用91、
            未使用92、未使用93、未使用94、未使用95、未使用96、未使用97、未使用98、未使用99、未使用100;
        スタック長++;
        テスト（）;
        未使用1 = 未使用2 = 未使用3 = 未使用4 = 未使用5 = 未使用6 = 未使用7 = 未使用8 = 未使用9 = 未使用10 = 未使用11 =
            未使用12 = 未使用13 = 未使用14 = 未使用15 = 未使用16 = 未使用17 = 未使用18 = 未使用19 = 未使用20 =
                未使用21 = 未使用22 = 未使用23 = 未使用24 = 未使用25 = 未使用26 = 未使用27 = 未使用28 = 未使用29 =
                    未使用30 = 未使用31 = 未使用32 = 未使用33 = 未使用34 = 未使用35 = 未使用36 = 未使用37 = 未使用38 =
                        未使用39 = 未使用40 = 未使用41 = 未使用42 = 未使用43 =
                            未使用44 = 未使用45 = 未使用46 = 未使用47 = 未使用48 = 未使用49 = 未使用50 = 未使用51 =
                                未使用52 = 未使用53 = 未使用54 = 未使用55 = 未使用56 = 未使用57 = 未使用58 = 未使用59 =
                                    未使用60 = 未使用61 = 未使用62 = 未使用63 = 未使用64 = 未使用65 = 未使用66 =
                                        未使用67 = 未使用68 = 未使用69 = 未使用70 = 未使用71 = 未使用72 = 未使用73 =
                                            未使用74 = 未使用75 = 未使用76 = 未使用77 = 未使用78 = 未使用79 = 未使用80 =
                                                未使用81 = 未使用82 = 未使用83 = 未使用84 = 未使用85 = 未使用86 =
                                                    未使用87 = 未使用88 = 未使用89 = 未使用90 = 未使用91 = 未使用92 =
                                                        未使用93 = 未使用94 = 未使用95 =
                                                            未使用96 = 未使用97 = 未使用98 = 未使用99 = 未使用100 = 0;
    } 
 
公共 静的void main(String[] args) {
        試す {
            テスト（）;
        } キャッチ (エラー e) {
            システム。 out .println( "スタックの長さ:" + stackLength);
            eを投げる;
        }
    }
 }

出力：

スタック長:6986
スレッド「main」で例外が発生しましたjava.lang.StackOverflowError
 cn.zhengsh.jvm.oom.JavaVMStackSOF2.test(JavaVMStackSOF2.java:22)で
cn.zhengsh.jvm.oom.JavaVMStackSOF2.test(JavaVMStackSOF2.java:22)で

要約する

スタックフレームが大きすぎるか、仮想マシンのスタック容量が小さすぎるため、新しいスタックフレームメモリを割り当てることができない場合、HotSpot 仮想マシンは StackOverflowError 例外をスローします。ただし、スタック容量の動的な拡張が可能な仮想マシン上で同じコードを使用すると、状況は異なります。

スレッドを作成するとメモリオーバーフローが発生する

注意: 次の実験を行うと、オペレーティングシステムがフリーズする可能性があります。仮想マシンで実行することをお勧めします。

 /**
 * VM引数: -Xss512k
 *
 * @著者 鄭sh
 * @日付2021-08-13
 */
パブリッククラスJavaVMStackOOM { 
     
    プライベートvoid dontStop() {
        （真）の間{
        }
    } 
 
パブリックvoid スタックリークByThread() {
        （真）の間{
            スレッド thread = new Thread(new Runnable() {
                @オーバーライド
パブリックボイド実行（）{
                    停止しないでください();
                }
            });
            スレッドを開始します。
        }
    } 
 
公共 静的void main(String[] args) throws Throwable {
        JavaVMStackOOM oom = 新しい JavaVMStackOOM();
        oom.stackLeakByThread();
    }
 }

メソッド領域とランタイム定数プールのオーバーフロー

ランタイム定数プールはメソッド領域の一部であるため、これら 2 つの領域のオーバーフローテストを一緒に実行できます。 HotSpot は JDK 7 から徐々に「永続世代をなくす」計画を開始し、JDK 8 ではメタスペースを完全に使用して永続世代を置き換えました。

メソッド領域のメモリオーバーフロー

メソッド領域の主な役割は、クラス名、アクセス修飾子、定数プール、フィールドの説明、メソッドの説明などの型関連の情報を保存することです。この領域をテストするための基本的な考え方は、実行時に大量のクラスを生成し、メソッド領域がオーバーフローするまで埋めることです。 Java SE API（GeneratedConstructorAccessorやリフレクション時の動的プロキシなど）を直接使用することでクラスを動的に生成することもできますが、今回の実験ではCGLibの助けを借りてバイトコードランタイムを直接操作することで、大量の動的クラスを生成しました。

 /**
 * VM引数: -XX:MetaspaceSize=21m -XX:MaxMetaspaceSize=21m
 *
 * @著者 鄭sh
 * @日付2021-08-13
 */
パブリッククラスJavaMethodAreaOOM {
公共 静的void main(String[] args) {
        （真）の間{
            エンハンサー enhancer = new Enhancer();
            エンハンサー.setSuperclass(OOMObject.class);
            エンハンサー.setUseCache( false );
            エンハンサー.setCallback(新しいMethodInterceptor() {
                @オーバーライド
パブリックオブジェクトインターセプト(オブジェクトobj、メソッドメソッド、オブジェクト[]引数、メソッドプロキシプロキシ)はThrowableをスローします{
 proxy.invokeSuper(obj, args)を返します。
                }
            });
            エンハンサーを作成します();
        }
    } 
 
静的クラスOOMObject {
    }
 }

出力コード

原因: java.lang.OutOfMemoryError: Metaspace
原因: java.lang.OutOfMemoryError: Metaspace

定数プールの例

String::intern() は、文字列定数プールにこの String オブジェクトと等しい文字列がすでに含まれている場合に、プール内の文字列を表す String オブジェクトへの参照を返すネイティブメソッドです。それ以外の場合、この String オブジェクトに含まれる文字列が定数プールに追加され、この String オブジェクトへの参照が返されます。 JDK 6 以前の HotSpot 仮想マシンでは、定数プールは永続世代に割り当てられます。 -XX:PermSize と -XX:MaxPermSize を通じて永続世代のサイズを制限できます。これにより、定数プールの容量が間接的に制限されます。

 /**
 * @著者 鄭sh
 * @日付2021-08-13
 */
パブリッククラスRuntimeConstantPoolOOM2 {
公共 静的void main(String[] args) {
        文字列 str1 = new StringBuilder( "Computer" ).append( "Software" ).toString();
        システム。出力.println(str1.intern() == str1);
        文字列 str2 = new StringBuilder( "ja" ).append( "va" ).toString();
        システム。出力.println(str2.intern() == str2);
    }
 }

このコードを JDK 6 で実行すると、2 つの false 値が生成されますが、JDK 7 で実行すると、1 つの true 値と 1 つの false 値が生成されます。違いが生じる理由は、JDK 6 では、 intern() メソッドが最初に検出された文字列インスタンスを永続世代の文字列定数プールにコピーして保存し、永続世代の文字列インスタンスへの参照を返すためです。 StringBuilder によって作成された文字列オブジェクトインスタンスは Java ヒープ上にあるため、同じ参照になることはできず、結果は false を返します。 JDK 7 (および JRockit などの他の仮想マシン) の intern() メソッド実装では、文字列インスタンスを永続世代にコピーする必要がなくなりました。文字列定数プールは Java ヒープに移動されているため、定数プール内の最初のインスタンス参照のみを記録する必要があります。したがって、intern() によって返される参照は、StringBuilder によって作成された文字列インスタンスと同じです。 str2 の比較は false を返します。これは、String-Builder.toString() の実行前に文字列「java」がすでに出現しており、その参照がすでに文字列定数プール内にあるため、intern() メソッドで要求される「最初の遭遇」の原則を満たしていないためです。文字列「コンピュータソフトウェア」は初めて出現するため、結果は true を返します。

このマシンの直接メモリオーバーフロー

直接メモリの容量は、-XX:MaxDirectMemorySize パラメータで指定できます。デフォルトでは、Java ヒープの最大値 (-Xmx で指定) と一致します。このコードは、DirectByteBuffer クラスをバイパスし、メモリ割り当てのリフレクションを介して Unsafe インスタンスを直接取得します (Unsafe クラスの getUnsafe() メソッドは、ブートストラップクラスローダーのみがインスタンスを返すように指定しており、これは、仮想マシンの標準クラスライブラリ内のクラスのみが Unsafe 関数を使用できるようにするという設計者の希望を反映しています。JDK 10 では、Unsafe の一部の関数が VarHandle を介して外部使用に開放されました)。 DirectByteBuffer はメモリを割り当てるときにメモリオーバーフロー例外をスローしますが、例外をスローするときにオペレーティングシステムにメモリ割り当てを実際に要求するわけではありません。代わりに、計算によってメモリを割り当てることができないことがわかった場合は、コード内でオーバーフロー例外を手動でスローします。メモリ割り当てを要求する実際のメソッドは Unsafe::allocateMemory() です。

 /**
 * VM引数: -Xmx20M -XX:MaxDirectMemorySize=10M
 *
 * @著者 鄭sh
 * @日付2021-08-13
 */
パブリッククラス DirectMemoryOOM {
    プライベート静的最終int _1MB = 1024 * 1024; 
 
公共 静的void main(String[] args)は例外をスローします{
        フィールド unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible( true );
        安全でない unsafe = (Unsafe)unsafeField.get( null );
        （真）の間{
            安全ではありません。メモリを割り当てます(_1MB);
        }
    }
 }

出力：

スレッド「main」で例外が発生しましたjava.lang.OutOfMemoryError
スレッド「main」で例外が発生しましたjava.lang.OutOfMemoryError 
 
 java.base/jdk.internal.misc.Unsafe.allocateMemory(Unsafe.java:616)で
jdk.unsupported/sun.misc.Unsafe.allocateMemory(Unsafe.java:462)で
cn.zhengsh.jvm.oom.DirectMemoryOOM.main(DirectMemoryOOM.java:21)で