エラーjava.lang.OutOfMemoryError：GCオーバーヘッド制限を超えました

JUnitテストを実行すると、次のエラーメッセージが表示されます。

java.lang.OutOfMemoryError: GC overhead limit exceeded

私はそれが何であるかを知っていますOutOfMemoryErrorが、GCオーバーヘッド制限は何を意味しますか？どうすればこれを解決できますか？

このメッセージは、なんらかの理由でガベージコレクターが過度の時間（デフォルトではプロセスのすべてのCPU時間の98％）を消費し、各実行でメモリをほとんど回復しない（デフォルトではヒープの2％）ことを意味します。

これは事実上、プログラムが進行を停止し、常にガベージコレクションのみの実行でビジーであることを意味します。

アプリケーションが何もせずにCPU時間を消費するのを防ぐために、JVMはこれをスローしErrorて、問題を診断する機会を得ます。

これが発生するまれなケースは、一部のコードが、大量の一時オブジェクトと大量の弱参照オブジェクトを、非常にメモリに制約のある環境で作成していた場合です。

さまざまなJavaバージョンで利用可能で、この特定の問題に関するセクションが含まれているJava GCチューニングガイドを確認してください。

• Java 11チューニングガイドには、さまざまなガベージコレクターのための過剰なGCに関する専用セクションがあります。
  • 以下のための並列コレクター
  • 以下のための並行マークスイープ（CMS）コレクタ
  • ガベージファースト（G1）コレクターに関するこの特定のエラー状態についての言及はありません。
• Java 8チューニングガイドとその過剰なGCセクション
• Java 6チューニングガイドとその過剰なGCセクション。

Oracleの記事「Java SE 6 HotSpot [tm] Virtual Machine Garbage Collection Tuning」からの引用：

過剰なGC時間とOutOfMemoryError

ガベージコレクションに費やされている時間が多すぎる場合、パラレルコレクターはOutOfMemoryErrorをスローします。ガベージコレクションに費やされた合計時間が98％を超え、回復されたヒープが2％未満の場合、OutOfMemoryErrorがスローされます。この機能は、ヒープが小さすぎるため、ほとんどまたはまったく進行せずに、アプリケーションが長期間実行されないようにするために設計されています。必要に応じ-XX:-UseGCOverheadLimitて、コマンドラインにオプションを追加して、この機能を無効にすることができます。

編集：誰かが私より速くタイプできるように見えます:)

プログラムにメモリリークがないことが確かな場合は、次のことを試してください。

1. たとえば、ヒープサイズを増やします-Xmx1g。
2. 同時ローポーズコレクターを有効にし-XX:+UseConcMarkSweepGCます。
3. 可能な場合は既存のオブジェクトを再利用して、メモリを節約します。

必要に応じて、コマンドラインにオプションを追加することで、制限チェックを無効にすることができます-XX:-UseGCOverheadLimit。

通常はコードです。以下に簡単な例を示します。

import java.util.*;

public class GarbageCollector {

    public static void main(String... args) {

        System.out.printf("Testing...%n");
        List<Double> list = new ArrayList<Double>();
        for (int outer = 0; outer < 10000; outer++) {

            // list = new ArrayList<Double>(10000); // BAD
            // list = new ArrayList<Double>(); // WORSE
            list.clear(); // BETTER

            for (int inner = 0; inner < 10000; inner++) {
                list.add(Math.random());
            }

            if (outer % 1000 == 0) {
                System.out.printf("Outer loop at %d%n", outer);
            }

        }
        System.out.printf("Done.%n");
    }
}

Windows 7 32ビットでのJava 1.6.0_24-b07の使用。

java -Xloggc:gc.log GarbageCollector

次に見て gc.log

• BADメソッドを使用して444回トリガー
• WORSEメソッドを使用して666回トリガー
• BETTERメソッドを使用して354回トリガー

当然のことながら、これは最良のテストでも最良の設計でもありませんが、そのようなループを実装せざるを得ない状況に直面した場合や、動作が悪い既存のコードを処理する場合、新しいものを作成する代わりにオブジェクトを再利用することを選択すると、ガベージコレクターが邪魔する回数...

Java [8] Platform、Standard Editionトラブルシューティングガイドによるエラーの原因：（強調と改行が追加されました）

[...]「GCオーバーヘッド制限を超えました」は、ガベージコレクターが常に実行されていて、Javaプログラムの進行が非常に遅いことを示しています。

ガベージコレクションの後、Javaプロセスがガベージコレクションに費やす時間の約98％以上を費やしていて、ヒープの2％未満しか回復せず、これまでに最後の5（コンパイル時定数）ガベージを実行している場合コレクション、次にjava.lang.OutOfMemoryErrorスローされます。[...]

1. 現在のヒープが十分でない場合は、ヒープサイズを増やします。
2. あなたはまだヒープメモリ、使用メモリ増加した後に、このエラーが発生した場合プロファイリングツールのようなMAT（メモリー・アナライザツール）、 ビジュアルVMなどと修正メモリリークを。
3. JDKバージョンを最新バージョン（1.8.x）または少なくとも1.7.xにアップグレードし、G1GCアルゴリズムを使用します。。G1 GCのスループット目標は、90％のアプリケーション時間と10％のガベージコレクション時間です。

4. - Xms1g -Xmx2gでヒープメモリを設定する以外に、

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

G1GCに関するいくつかの関連質問をご覧ください

• G1でのJava 7（JDK 7）ガベージコレクションとドキュメント

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

• GCの微調整に関するOracle technetworkの記事

このオプションを次のように設定して、ヒープサイズを少し増やします。

実行→実行構成→引数→VM引数

-Xms1024M -Xmx2048M

Xms-最小制限

Xmx-最大制限

私にとっては、次の手順が機能しました：

1. eclipse.iniファイルを開く

2. 変化する

   -Xms40m
   -Xmx512m

   に

   -Xms512m
   -Xmx1024m

3. Eclipseを再起動します

こちらをご覧ください

これを試して

build.gradleファイルを 開く

  android {
        dexOptions {
           javaMaxHeapSize = "4g"
        }
   }

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

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

defaultConfig {
        applicationId "yourpackage"
        minSdkVersion 10
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
        multiDexEnabled true
    }
dexOptions {
        javaMaxHeapSize "4g"
    }
}

build.gradle（Module：app）ファイルのjavaMaxHeapsizeを増やします

dexOptions {
    javaMaxHeapSize "1g"
}

へ（この行をgradleに追加）

 dexOptions {
        javaMaxHeapSize "4g"
    }

Javaヒープサイズの説明（xms、xmx、xmn）

-Xms size in bytes

Example : java -Xms32m

Javaヒープの初期サイズを設定します。デフォルトのサイズは2097152（2MB）です。値は、1024バイト（1KB）の倍数以上でなければなりません。（-serverフラグは、デフォルトのサイズを32Mに増やします。）

-Xmn size in bytes

Example : java -Xmx2m

Eden世代の初期Javaヒープサイズを設定します。デフォルト値は640Kです。（-serverフラグは、デフォルトのサイズを2Mに増やします。）

-Xmx size in bytes

Example : java -Xmx2048m

Javaヒープが拡張できる最大サイズを設定します。デフォルトのサイズは64Mです。（-serverフラグはデフォルトのサイズを128Mに増やします。）最大ヒープ制限は約2 GB（2048MB）です。

Javaメモリ引数（xms、xmx、xmn）のフォーマット

Javaヒープサイズを設定するときは、MBの場合は「m」または「M」、GBの場合は「g」または「G」のいずれかの文字を使用してメモリ引数を指定する必要があります。「MB」または「GB」を指定した場合、設定は機能しません。有効な引数は次のようになります。

-Xms64mまたは-Xms64M -Xmx1gまたは-Xmx1G 2048MBを使用して2GBを指定することもできますまた、引数を指定するときは、整数のみを使用するようにしてください。-Xmx512mの使用は有効なオプションですが、-Xmx0.5gを使用するとエラーが発生します。

この参照は、誰かに役立つ場合があります。

これをgradle.propertiesファイルに追加して、メモリ割り当てとヒープサイズを増やすこともできます。

org.gradle.jvmargs=-Xmx2048M -XX\:MaxHeapSize\=32g

2048Mや32gでなくてもかまいません。

解決済み：
追加するだけ
org.gradle.jvmargs=-Xmx1024m
で
gradle.properties
、存在しない場合は作成します。

Android Studioで作業していて、リリース用の署名済みAPKを生成しようとしたときにこのエラーが発生しました。問題なくデバッグAPKをビルドしてテストすることができましたが、リリースAPKをビルドしたいとすぐに、ビルドプロセスが最後まで数分間実行され、最後に「エラーjava.lang.OutOfMemoryError：GCで終了しました。オーバーヘッド制限を超えました。」VMとAndroid DEXコンパイラの両方のヒープサイズを増やしましたが、問題は解決しませんでした。最後に、何時間もコーヒーを飲み続けた後、問題はアプリレベルの「build.gradle」ファイルにあることがわかりました-リリースビルドタイプの「minifyEnabled」パラメーターを「false」に設定し、その結果Proguardを実行しましたコード圧縮プロセスを経ていないコード（https://developer.android。）。「minifyEnabled」パラメーターを「true」に変更すると、リリースビルドが夢のように実行されました:)

つまり、アプリレベルの「build.gradle」ファイルを/// ...から変更する必要がありました。

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

に

    //...

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

IntelliJ IDEAでヒープサイズを増やすには、次の手順に従います。それは私のために働いた。

Windowsユーザーの場合

IDEがインストールされている場所に移動し、以下を検索します。

idea64.exe.vmoptions

ファイルを編集して、以下を追加します。

-Xms512m
-Xmx2024m
-XX:MaxPermSize=700m
-XX:ReservedCodeCacheSize=480m

それだ ！！

この画像を参照してサーバー設定を変更して、黄色で強調表示されているプロセス変更を処理するためのメモリサイズを増やすことができます。

set _java_opts -Xmx2g
プログラムの複雑さに応じて、cmd-> 2g（2gigabytes）を開いてjavaヒープを変更することもできます

定数の少ない変数と一時的な変数を使用してみてください

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**
)

そして

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**

Netbeansでは、最大ヒープサイズを設計すると役立つ場合があります。[ 実行] => [ プロジェクト構成の設定] => [ カスタマイズ]に移動します。で実行そのポップアップウィンドウの、に行くVMオプション、中塗り-Xms2048m -Xmx2048m。ヒープサイズの問題を解決できます。

MacBookを再起動すると、この問題は解決しました。

これがまだ関連性があるかどうかはわかりませんが、私のために機能したことを共有したいだけです。

kotlinのバージョンを最新のものに更新します。https://blog.jetbrains.com/kotlin/category/releases/

これで完了です。