JAVA HEAP GC предел превышен или выходит из памяти при выполнении обработки естественного языка stanford api [duplicate]

Я работаю в Android Studio и столкнулся с этой ошибкой при попытке создать подписанный APK для выпуска. Мне удалось создать и протестировать отладочную APK без проблем, но как только я захочу создать APK выпуска, процесс сборки будет работать в течение нескольких минут подряд, а затем окончательно завершится с помощью «Ошибка java.lang.OutOfMemoryError: GC превышение верхнего предела ". Я увеличил размеры кучи как для VM, так и для компилятора Android DEX, но проблема не устранена. Наконец, после многих часов и кружек кофе выяснилось, что проблема была в моем файле buildGradle на уровне приложения. У меня был параметр minifyEnabled для типа сборки релиза, установленного на «ложь», и, следовательно, работа с продуктами Proguard по коду, который не прошел через процесс сжатия кода (см. https://developer.android.com/studio/build/shrink-code.html ). Я изменил параметр «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
    }
}

//...

попробуйте это

откройте файл build.gradle

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

Причина для ошибки

превышен превышение лимита 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

Сбор мусора и документация по G7 [JGK 7] для G1

Сбор мусора Java G1 в производстве

Статья о технической службе Oracle для GC finetuning

Чтобы увеличить размер кучи в IntelliJ IDEA, следуйте приведенным ниже инструкциям. Это работало для меня.

Для пользователей Windows

Перейдите в место, где установлена ​​среда IDE, и выполните поиск следующего.

idea64.exe.vmoptions

Отредактируйте файл и добавьте следующее.

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

Вот и все!

Следующие работали для меня. Просто добавьте следующий фрагмент:

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

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

Обычно это код. Вот простой пример:

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 На 32-разрядной версии Windows 7.

java -Xloggc: gc.log GarbageCollector

Затем посмотрите на gc.log

• Запущено 444 раза с использованием метода BAD
• Запущено 666 раз с использованием метода WORSE
• Триггер 354 раза с использованием метода BETTER
g2]

Теперь предоставлено, это не лучший тест или лучший дизайн, но когда вы столкнулись с ситуацией, когда у вас нет выбора, кроме как реализовать такой цикл или при работе с существующим кодом, который ведет себя плохо, выбирая повторное использование объектов вместо создания новых может уменьшить количество сборов сборщика мусора на пути ...

Для меня были выполнены следующие шаги:

1. Откройте файл eclipse.ini
2. Измените

   -Xms40m
   -Xmx512m
   

   на

   -Xms512m
   -Xmx1024m
   

3. Перезапустите Eclipse

См. Здесь

В Netbeans может оказаться полезным создать максимальный размер кучи. Перейдите к Выполнить => Установить конфигурацию проекта => Настроить . В появившемся окне Run перейдите к опции VM Option , заполните -Xms2048m -Xmx2048m. Это может решить проблему размера кучи.

увеличить javaMaxHeapsize в файле build.gradle (Module: app)

dexOptions {
    javaMaxHeapSize "1g"
}

до (добавьте эту строку в градус)

 dexOptions {
        javaMaxHeapSize "4g"
    }

Вам нужно увеличить размер памяти в 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**

Если вы уверены, что в вашей программе нет утечек памяти , попробуйте:

1. Увеличьте размер кучи, например -Xmx1g.
2. Включить параллельный сборщик низких пауз -XX:+UseConcMarkSweepGC.
3. Повторно использовать существующие объекты, когда это возможно, чтобы сохранить некоторую память.

При необходимости ограничение limit можно отключить, добавив опцию -XX:-UseGCOverheadLimit в командной строке.