Помилка java.lang.OutOfMemoryError: перевищено накладний ліміт GC

Я отримую це повідомлення про помилку під час виконання тестів JUnit:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Я знаю, що OutOfMemoryErrorтаке, але що означає накладний ліміт ГК? Як я можу це вирішити?

Це повідомлення означає, що з якихось причин збирач сміття займає надмірну кількість часу (за замовчуванням 98% всього процесорного часу процесу) та відновлює дуже мало пам’яті за кожен пробіг (за замовчуванням 2% купи).

Це фактично означає, що ваша програма перестає робити будь-який прогрес і зайнята тим, що весь час займається лише збиранням сміття.

Щоб ваш додаток не забирав час процесора, не вчинивши нічого, JVM передає це Errorтак, щоб у вас був шанс діагностувати проблему.

Рідкісні випадки, коли я бачив це, - це те, що якийсь код створював тонни тимчасових об'єктів і тонни слабко посилальних об'єктів у вже дуже обмеженій пам'яті середовищі.

Перегляньте посібник з налаштування Java GC, який доступний для різних версій Java та містить розділи щодо цієї конкретної проблеми:

• Посібник з тюнінгу Java 11 має спеціалізовані розділи щодо надмірної кількості GC для різних сміттєзбірників:
  • для паралельного колектора
  • для колекціонера одночасного розміщення знаків (CMS)
  • про цю специфічну умову помилки колектора Garbage First (G1) не згадується.
• Посібник з налаштування Java 8 та його розділ «Надмірна GC»
• Посібник з налаштування Java 6 та його розділ «Надмірна GC» .

Цитуючи статтю Oracle "Налаштування збирання сміття на віртуальній машині Java SE 6 HotSpot [tm]" :

Надмірний час GC та OutOfMemoryError

Паралельний збірник викине OutOfMemoryError, якщо на збирання сміття витрачається занадто багато часу: якщо на збирання сміття витрачається більше 98% від загального часу і відновлюється менше 2% купи, OutOfMemoryError буде викинутий. Ця функція призначена для запобігання запуску додатків протягом тривалого періоду, досягаючи незначного прогресу або не вимагаючи його, оскільки купа занадто мала. При необхідності цю функцію можна відключити, додавши параметр -XX:-UseGCOverheadLimitдо командного рядка.

EDIT: схоже, хтось може набрати швидше, ніж я :)

Якщо ви впевнені, що у вашій програмі немає витоків пам'яті , спробуйте:

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");
    }
}

Використання Java 1.6.0_24-b07 на Windows 7 32 біт.

java -Xloggc:gc.log GarbageCollector

Тоді подивіться gc.log

• Запускається 444 рази методом BAD
• Запускається 666 разів за допомогою методу WORSE
• Запускається 354 рази за допомогою методу BETTER

Зараз надано, це не найкращий тест чи найкращий дизайн, але якщо ви стикаєтесь із ситуацією, коли у вас немає іншого вибору, окрім впровадження такого циклу або при роботі з існуючим кодом, який поводиться погано, вибір повторного використання об'єктів замість створення нових може зменшити скільки разів смітник збирається на шляху ...

Причина помилки відповідно до платформи Java [8], Посібник з усунення неполадок у стандартній версії : (додано наголоси та розриви рядків)

[...] "Перевищений ліміт GC перевищує" вказує на те, що сміттєзбірник працює весь час, і програма Java робить дуже повільний прогрес.

Після збору сміття, якщо процес Java витрачає більше приблизно 98% свого часу на вивезення сміття, і якщо він відновлює менше 2% купи і до цього часу робив останні 5 (постійний час збирання) сміття поспіль колекції, то java.lang.OutOfMemoryErrorкидається а. [...]

1. Збільшити розмір купи, якщо поточної купи недостатньо.
2. Якщо ви все-таки отримаєте цю помилку після збільшення накопичувальної пам’яті, використовуйте засоби профілювання пам’яті , такі як MAT (інструмент аналізатора пам’яті), Visual 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 у виробництві

• Стаття Oracle Technetwork для GC finetuning

Просто трохи збільшить розмір купи, встановивши цю опцію в

Виконати → Запустити конфігурації → Аргументи → Аргументи VM

-Xms1024M -Xmx2048M

Xms - для мінімальної межі

Xmx - для максимальної межі

Для мене спрацювали наступні кроки:

1. Відкрийте eclipse.iniфайл

2. Зміна

   -Xms40m
   -Xmx512m

   до

   -Xms512m
   -Xmx1024m

3. Перезапустіть затемнення

Дивіться тут

спробуйте це

відкрити 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"
    }
}

збільшити javaMaxHeapsize у файлі build.gradle (Модуль: додаток)

dexOptions {
    javaMaxHeapSize "1g"
}

до (Додати цей рядок у gradle)

 dexOptions {
        javaMaxHeapSize "4g"
    }

Описи розміру кучі Java (xms, xmx, xmn)

-Xms size in bytes

Example : java -Xms32m

Встановлює початковий розмір купи Java. За замовчуванням розмір - 2097152 (2 МБ). Значення повинні бути кратними та більшими 1024 байт (1 КБ). (Прапор -server збільшує розмір за замовчуванням до 32М.)

-Xmn size in bytes

Example : java -Xmx2m

Встановлює початковий розмір кучі Java для покоління Eden. Значення за замовчуванням - 640K. (Прапор -server збільшує розмір за замовчуванням до 2М.)

-Xmx size in bytes

Example : java -Xmx2048m

Встановлює максимальний розмір, до якого може виростати купа Java. Типовий розмір - 64М. (Прапор -server збільшує розмір за замовчуванням до 128M.) Максимальна межа купи - близько 2 ГБ (2048 МБ).

Форматування аргументів пам'яті Java (xms, xmx, xmn)

Встановлюючи розмір купи Java, слід вказати аргумент пам’яті, використовуючи одну з літер «m» або «M» для MB, або «g» або «G» для GB. Налаштування не працюватиме, якщо ви вкажете "MB" або "GB". Дійсні аргументи виглядають приблизно так:

-Xms64m або -Xms64M -Xmx1g або -Xmx1G Також можна використовувати 2048MB для вказівки 2 Гб. Також обов’язково використовуйте цілі числа, коли вказуєте свої аргументи. Використання -Xmx512m є допустимим варіантом, але -Xmx0,5g призведе до помилки.

Ця довідка може бути корисною для когось.

Ви також можете збільшити розміщення пам'яті та розмір купи, додавши це у свій gradle.propertiesфайл:

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

Це не повинно бути 2048М і 32г, зробіть його таким же великим, як вам хочеться.

Вирішено:
Просто додайте
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

Це все !!

ви можете спробувати внести зміни в налаштування сервера, звернувшись до цього зображення та збільшити розмір пам'яті для змін процесу обробки, виділених жовтим кольором

Ви також можете внести зміни в java heap, відкривши cmd-> set _java_opts -Xmx2g
2g (2 гігабайти) залежно від складності вашої програми.

спробуйте використовувати менш постійні змінні та тимчасові змінні

Вам потрібно збільшити розмір пам'яті в 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 Option , заповніть -Xms2048m -Xmx2048m. Це може вирішити проблему розміру купи.

Перезавантаження мого MacBook вирішило цю проблему для мене.

Я не знаю, це все ще актуально чи ні, але просто хочу поділитися тим, що працювало на мене.

Оновіть версію kotlin до останньої доступної. https://blog.jetbrains.com/kotlin/category/releases/

і це зроблено.