java - java.lang.OutOfMemoryError: GC オーバーヘッドの制限を超えました

Question

それぞれ数個 (15 ～ 20 個) のテキストエントリを持つ数個 (数十万個) の HashMap オブジェクトを作成するプログラムで、このエラーが発生します。これらの文字列は、データベースに送信される前にすべて (少量に分割せずに) 収集する必要があります。

Sun によると、エラーは「ガベージコレクションに費やされている時間が長すぎる場合に発生します。総時間の 98% 以上がガベージコレクションに費やされ、回復されたヒープが 2% 未満の場合、OutOfMemoryError がスローされます。 "。

どうやら、コマンドラインを使用してJVMに引数を渡すことができます

「-Xmx1024m」（またはそれ以上）を介してヒープサイズを増やす、または
「-XX:-UseGCOverheadLimit」を使用して、エラーチェックを完全に無効にします。

最初のアプローチは問題なく機能しますが、2 番目のアプローチは別の java.lang.OutOfMemoryError で終わります。今回はヒープに関するものです。

では、質問: 特定のユースケース (つまり、いくつかの小さな HashMap オブジェクト) に対して、これに代わるプログラムはありますか? たとえば、HashMap の clear() メソッドを使用すると、問題は解消されますが、HashMap に格納されているデータも解消されます。:-)

この問題は、StackOverflow の関連トピックでも説明されています。

score 157 · Accepted Answer

プロセスをスムーズに実行するには、基本的にメモリが不足しています。頭に浮かぶオプション：

あなたが言及したようにより多くのメモリを指定し、-Xmx512m最初のような間に何かを試してください
HashMap可能であれば、一度に処理するオブジェクトの小さなバッチで作業する
重複する文字列がたくさんある場合は、String.intern()それらをHashMap
HashMap(int initialCapacity, float loadFactor)コンストラクターを使用してケースに合わせて調整する

score 61 · Accepted Answer

以下は私のために働いた。次のスニペットを追加するだけです。

dexOptions {
        javaMaxHeapSize "4g"
}

あなたにbuild.gradle：

android {
    compileSdkVersion 23
    buildToolsVersion '23.0.1'

    defaultConfig {
        applicationId "yourpackage"
        minSdkVersion 14
        targetSdkVersion 23
        versionCode 1
        versionName "1.0"

        multiDexEnabled true
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    packagingOptions {

    }

    dexOptions {
        javaMaxHeapSize "4g"
    }
}

score 43 · Accepted Answer

@takrl: このオプションのデフォルト設定は次のとおりです。

java -XX:+UseConcMarkSweepGC

つまり、このオプションはデフォルトではアクティブではありません。したがって、オプション " " を使用したと言うときは、次の+XX:UseConcMarkSweepGC構文を使用していたと思います。

java -XX:+UseConcMarkSweepGC

これは、このオプションを明示的に有効にしたことを意味します。Java HotSpot VM Options@ の正しい構文とデフォルト設定については、このドキュメントを参照してください。

score 24 · Accepted Answer

ちなみに、今日も同じ問題がありました。このオプションを使用して修正しました。

-XX:-UseConcMarkSweepGC

どうやら、これはガベージコレクションに使用される戦略を変更し、問題を解消しました。

score 11 · Accepted Answer

うーん...次のいずれかが必要です。

これらの小さな HashMap をすべて必要としないように、アルゴリズムとデータ構造を完全に再考してください。
これらの HashMap を必要に応じてメモリの内外にページングできるようにするファサードを作成します。単純な LRU キャッシュは単なるチケットかもしれません。
JVM で使用できるメモリを増やします。この獣をホストするマシンを管理している場合は、必要に応じて、さらに RAM を購入することが最も迅速で安価なソリューションになる可能性があります。そうは言っても、私は通常、「ハードウェアをさらに投入する」ソリューションのファンではありません。特に、代替のアルゴリズムソリューションが妥当な時間枠内で考えられる場合はなおさらです。これらの問題のすべてにさらに多くのハードウェアを投入し続けると、すぐに収穫逓減の法則に突き当たります。

とにかく、あなたは実際に何をしようとしていますか？あなたの実際の問題に対するより良いアプローチがあると思います。

score 10 · Accepted Answer

別の HashMap 実装 ( Trove ) を使用します。標準の Java HashMap には、12 倍を超えるメモリオーバーヘッドがあります。ここで詳細を読むことができます。

score 9 · Accepted Answer

最後に到達するのを待っている間、構造全体をメモリに保存しないでください。

中間結果をハッシュマップの代わりにデータベースの一時テーブルに書き込みます。機能的には、データベーステーブルはハッシュマップと同等です。つまり、どちらもデータへのキー付きアクセスをサポートしますが、テーブルはメモリバウンドではありません。ハッシュマップ。

正しく行われた場合、アルゴリズムは変更に気付かないはずです。ここでは、クラスを使用してテーブルを表すことを意味し、ハッシュマップのように put(key, value) および get(key) メソッドを与えます。

中間テーブルが完成したら、メモリからではなく中間テーブルから必要な sql ステートメントを生成します。

score 3 · Accepted Answer

Eclipse MAT やVisualVMなどのプロファイルツールを使用して、アプリケーションのメモリリークを修正します。

JDK 1.7.x以降のバージョンでは、他の GC アルゴリズムの 2% とは異なり、ガベージコレクションに 10% を費やすを使用しG1GCます。

でヒープメモリを設定する以外に-Xms1g -Xmx2g、 ` を試してください

-XX:+UseG1GC 
-XX:G1HeapRegionSize=n, 
-XX:MaxGCPauseMillis=m, 
-XX:ParallelGCThreads=n, 
-XX:ConcGCThreads=n`

これらのパラメータの微調整については、Oracle の記事を参照してください。

SE の G1GC に関するいくつかの質問:

Java 7 (JDK 7) ガベージコレクションと G1 に関するドキュメント

本番環境での Java G1 ガベージコレクション

積極的なガベージコレクター戦略

score 3 · Accepted Answer

これを行うには、Android クロージャーの下でアプリの gradle ファイルで以下のコードを使用します。

dexOptions { javaMaxHeapSize "4g" }

score 2 · Accepted Answer

Jdeveloper の setDomainEnv.cmd でメモリサイズを増やす必要があります。

set WLS_HOME=%WL_HOME%\server
set XMS_SUN_64BIT=256
set XMS_SUN_32BIT=256
set XMX_SUN_64BIT=3072
set XMX_SUN_32BIT=3072
set XMS_JROCKIT_64BIT=256
set XMS_JROCKIT_32BIT=256
set XMX_JROCKIT_64BIT=1024
set XMX_JROCKIT_32BIT=1024

if "%JAVA_VENDOR%"=="Sun" (
    set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512m
    set WLS_MEM_ARGS_32BIT=-Xms256m -Xmx512m
) else (
    set WLS_MEM_ARGS_64BIT=-Xms512m -Xmx512m
    set WLS_MEM_ARGS_32BIT=-Xms512m -Xmx512m
)
and

set MEM_PERM_SIZE_64BIT=-XX:PermSize=256m
set MEM_PERM_SIZE_32BIT=-XX:PermSize=256m

if "%JAVA_USE_64BIT%"=="true" (
    set MEM_PERM_SIZE=%MEM_PERM_SIZE_64BIT%

) else (
    set MEM_PERM_SIZE=%MEM_PERM_SIZE_32BIT%
)

set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=1024m
set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=1024m

score 2 · Accepted Answer

In case of the error:

"Internal compiler error: java.lang.OutOfMemoryError: GC overhead limit exceeded at java.lang.AbstractStringBuilder"

increase the java heap space to 2GB i.e., -Xmx2g.

score 0 · Accepted Answer

これにより、このエラーを取り除くことができました。このオプションは -XX:+DisableExplicitGC を無効にします。

java - java.lang.OutOfMemoryError: GC オーバーヘッドの制限を超えました

16 に答える 16

Related

Reference