Java lang outofmemoryerror gc overhead limit exceeded как исправить

Java heap size descriptions (xms, xmx, xmn)

-Xms size in bytes

Example : java -Xms32m

Sets the initial size of the Java heap.
The default size is 2097152 (2MB).
The values must be a multiple of, and greater than, 1024 bytes (1KB).
(The -server flag increases the default size to 32M.)

-Xmn size in bytes

Example : java -Xmx2m

Sets the initial Java heap size for the Eden generation.
The default value is 640K.
(The -server flag increases the default size to 2M.)

-Xmx size in bytes

Example : java -Xmx2048m

Sets the maximum size to which the Java heap can grow.
The default size is 64M.
(The -server flag increases the default size to 128M.)
The maximum heap limit is about 2 GB (2048MB).

Java memory arguments (xms, xmx, xmn) formatting

When setting the Java heap size, you should specify your memory argument using one of the letters “m” or “M” for MB, or “g” or “G” for GB. Your setting won’t work if you specify “MB” or “GB.” Valid arguments look like this:

-Xms64m or -Xms64M
-Xmx1g or -Xmx1G
Can also use 2048MB to specify 2GB
Also, make sure you just use whole numbers when specifying your arguments. Using -Xmx512m is a valid option, but -Xmx0.5g will cause an error.

This reference can be helpful for someone.


1. Обзор

Проще говоря, JVM заботится об освобождении памяти, когда объекты больше не используются; этот процесс называется сбором мусора (ссылка:/jvm-garbage-collectors[GC]).

Ошибка

GC Overhead Limit Exceeded

относится к семейству

java.lang.OutOfMemoryError

и указывает на исчерпание ресурса (памяти).

В этой быстрой статье мы рассмотрим причину ошибки

java.lang.OutOfMemoryError: GC Overhead Limit Exceeded

и ее решение.


2. Ошибка превышения предельного значения GC


OutOfMemoryError

является подклассом

java.lang.VirtualMachineError

; он генерируется JVM, когда сталкивается с проблемой, связанной с использованием ресурсов. В частности,

ошибка возникает, когда JVM тратит слишком много времени на сборку мусора

и может освободить только очень мало места в куче.

Согласно документации Java, по умолчанию JVM настроена на выдачу этой ошибки, если процесс Java тратит более 98% своего времени на выполнение GC, и когда при каждом запуске восстанавливается только менее 2% кучи. Другими словами, это означает, что наше приложение исчерпало почти всю доступную память, а сборщик мусора потратил слишком много времени, пытаясь его очистить, и неоднократно выходил из строя.

В этой ситуации пользователи испытывают крайнюю медлительность приложения.

Некоторые операции, которые обычно выполняются за миллисекунды, занимают больше времени. Это связано с тем, что процессор использует всю свою емкость для сборки мусора и, следовательно, не может выполнять какие-либо другие задачи.


3. Ошибка в действии

Давайте рассмотрим фрагмент кода, который генерирует __java.lang.OutOfMemoryError

Превышен предел накладных расходов GC.

Мы можем достичь этого, например, добавив пары ключ-значение в неопределенный цикл:

public class OutOfMemoryGCLimitExceed {
    public static void addRandomDataToMap() {
        Map<Integer, String> dataMap = new HashMap<>();
        Random r = new Random();
        while (true) {
            dataMap.put(r.nextInt(), String.valueOf(r.nextInt()));
        }
    }
}

Когда этот метод вызывается с аргументами JVM, такими как


_- Xmx100m -XX: + UseParallelGC (размер кучи


Java установлен на 100 МБ, а алгоритм GC равен ParallelGC), мы получаем ошибку

java.lang.OutOfMemoryError: Ошибка превышения ограничения GC Exceeded_

. Чтобы лучше понять различные алгоритмы сбора мусора, мы можем обратиться к учебнику Oracle по

Java Garbage Collection Basics

учебнику.

Мы получим ошибку

java.lang.OutOfMemoryError: GC Overhead Limit Exceeded

очень быстро, выполнив следующую команду из корня

project

:

Следует также отметить, что в некоторых ситуациях мы можем столкнуться с ошибкой пространства кучи, прежде чем встретим ошибку

GC Overhead Limit Exceeded


4. Устранение ошибки превышения предельных значений ГХ

Идеальное решение – найти основную проблему с приложением, проверив код на наличие утечек памяти.

Необходимо ответить на следующие вопросы:

  • Какие объекты в приложении занимают большие порции

куча?

  • В каких частях исходного кода размещаются эти объекты?

Мы также можем использовать автоматизированные графические инструменты, такие как

JConsole

, которые помогают обнаруживать проблемы с производительностью в коде, включая

java.lang. .OutOfMemoryErrors.

Последним средством будет увеличение размера кучи путем изменения конфигурации запуска JVM. Например, это дает 1 ГБ пространства кучи для приложения Java:

java -Xmx1024m com.xyz.TheClassName

Однако это не решит проблему, если в реальном коде приложения есть утечки памяти. Вместо этого мы просто отложим ошибку.

Поэтому более целесообразно пересмотреть использование памяти приложением.


5. Заключение

В этом руководстве мы рассмотрели __java.lang.OutOfMemoryError: Превышен предел накладных расходов GC и причины его возникновения

Как всегда, исходный код, связанный с этой статьей, можно найти на

over на GitHub

.

java.lang.OutOfMemoryError:
GC overhead limit exceeded

Java runtime environment contains a built-in Garbage Collection (GC) process. In many other programming languages, the developers need to manually allocate and free memory regions so that the freed memory can be reused.

Java applications on the other hand only need to allocate memory. Whenever a particular space in memory is no longer used, a separate process called Garbage Collection clears the memory for them. How the GC detects that a particular part of memory is explained in more detail in the Garbage Collection Handbook, but you can trust the GC to do its job well.

The java.lang.OutOfMemoryError: GC overhead limit exceeded error is displayed when your application has exhausted pretty much all the available memory and GC has repeatedly failed to clean it.

What is causing it?

The java.lang.OutOfMemoryError: GC overhead limit exceeded error is the JVM’s way of signalling that your application spends too much time doing garbage collection with too little result. By default the JVM is configured to throw this error if it spends more than 98% of the total time doing GC and when after the GC only less than 2% of the heap is recovered.

java.lang.OutOfMemoryError: GC overhead limit exceeded

What would happen if this GC overhead limit would not exist? Note that the java.lang.OutOfMemoryError: GC overhead limit exceeded error is only thrown when 2% of the memory is freed after several GC cycles. This means that the small amount of heap the GC is able to clean will likely be quickly filled again, forcing the GC to restart the cleaning process again. This forms a vicious cycle where the CPU is 100% busy with GC and no actual work can be done. End users of the application face extreme slowdowns – operations which normally complete in milliseconds take minutes to finish.

So the “java.lang.OutOfMemoryError: GC overhead limit exceeded” message is a pretty nice example of a fail fast principle in action.

Give me an example

In the following example we create a “GC overhead limit exceeded” error by initializing a Map and adding key-value pairs into the map in an unterminated loop:


class Wrapper {
  public static void main(String args[]) throws Exception {
    Map map = System.getProperties();
    Random r = new Random();
    while (true) {
      map.put(r.nextInt(), "value");
    }
  }
}

As you might guess this cannot end well. And, indeed, when we launch the above program with:

java -Xmx100m -XX:+UseParallelGC Wrapper

we soon face the java.lang.OutOfMemoryError: GC overhead limit exceeded message. But the above example is tricky. When launched with different Java heap size or a different GC algorithm, my Mac OS X 10.9.2 with Hotspot 1.7.0_45 will choose to die differently. For example, when I run the program with smaller Java heap size like this:

java -Xmx10m -XX:+UseParallelGC Wrapper

the application will die with a more common java.lang.OutOfMemoryError: Java heap space message that is thrown on Map resize. And when I run it with other garbage collection algorithms besides ParallelGC, such as -XX:+UseConcMarkSweepGC or -XX:+UseG1GC, the error is caught by the default exception handler and is without stacktrace as the heap is exhausted to the extent where the stacktrace cannot even be filled on Exception creation.

These variations are truly good examples that demonstrate that in resource-constrained situations you cannot predict the way your application is going to die so do not base your expectations on a specific sequence of actions to be completed.

What is the solution?

As a tongue-in-cheek solution, if you just wished to get rid of the “java.lang.OutOfMemoryError: GC overhead limit exceeded” message, adding the following to your startup scripts would achieve just that:

-XX:-UseGCOverheadLimit

I would strongly suggest NOT to use this option though – instead of fixing the problem you just postpone the inevitable: the application running out of memory and needing to be fixed. Specifying this option will just mask the original java.lang.OutOfMemoryError: GC overhead limit exceeded error with a more familiar message java.lang.OutOfMemoryError: Java heap space.

On a more serious note – sometimes the GC overhead limit error is triggered because the amount of heap you have allocated to your JVM is just not enough to accommodate the needs of your applications running on that JVM. In that case, you should just allocate more heap – see at the end of this chapter for how to achieve that.

In many cases however, providing more Java heap space will not solve the problem. For example, if your application contains a memory leak, adding more heap will just postpone the java.lang.OutOfMemoryError: Java heap space error. Additionally, increasing the amount of Java heap space also tends to increase the length of GC pauses affecting your application’s throughput or latency.

If you wish to solve the underlying problem with the Java heap space instead of masking the symptoms, you need to figure out which part of your code is responsible for allocating the most memory. In other words, you need to answer these questions:

  1. Which objects occupy large portions of heap
  2. where these objects are being allocated in source code

At this point, make sure to clear a couple of days in your calendar (or – see an automated way below the bullet list). Here is a rough process outline that will help you answer the above questions:

  • Get clearance for acquiring a heap dump from your JVM-to-troubleshoot. “Dumps” are basically snapshots of heap contents that you can analyze, and contain everything that the application kept in memory at the time of the dump. Including passwords, credit card numbers etc.
  • Instruct your JVM to dump the contents of its heap memory into a file. Be prepared to get a few dumps, as when taken at a wrong time, heap dumps contain a significant amount of noise and can be practically useless. On the other hand, every heap dump “freezes” the JVM entirely, so don’t take too many of them or your end users start swearing.
  • Find a machine that can load the dump. When your JVM-to-troubleshoot uses for example 8GB of heap, you need a machine with more than 8GB to be able to analyze heap contents. Fire up dump analysis software (we recommend Eclipse MAT, but there are also equally good alternatives available).
  • Detect the paths to GC roots of the biggest consumers of heap. We have covered this activity in a separate post here. Don’t worry, it will feel cumbersome at first, but you’ll get better after spending a few days digging.
  • Next, you need to figure out where in your source code the potentially hazardous large amount of objects is being allocated. If you have good knowledge of your application’s source code you’ll hopefully be able to do this in a couple searches. When you have less luck, you will need some energy drinks to assist.

Alternatively, we suggest Plumbr, the only Java monitoring solution with automatic root cause detection. Among other performance problems it catches all java.lang.OutOfMemoryErrors and automatically hands you the information about the most memory-hungry data structres. It takes care of gathering the necessary data behind the scenes – this includes the relevant data about heap usage (only the object layout graph, no actual data), and also some data that you can’t even find in a heap dump. It also does the necessary data processing for you – on the fly, as soon as the JVM encounters an java.lang.OutOfMemoryError. Here is an example java.lang.OutOfMemoryError incident alert from Plumbr:
Plumbr OutOfMemoryError incident alert
Without any additional tooling or analysis you can see:

  • Which objects are consuming the most memory (271 com.example.map.impl.PartitionContainer instances consume 173MB out of 248MB total heap)
  • Where these objects were allocated (most of them allocated in the MetricManagerImpl class, line 304)
  • What is currently referencing these objects (the full reference chain up to GC root)

Equipped with this information you can zoom in to the underlying root cause and make sure the data structures are trimmed down to the levels where they would fit nicely into your memory pools.

However, when your conclusion from memory analysis or from reading the Plumbr report are that memory use is legal and there is nothing to change in the source code, you need to allow your JVM more Java heap space to run properly. In this case, alter your JVM launch configuration and add (or increase the value if present) just one parameter in your startup scripts:

java -Xmx1024m com.yourcompany.YourClass

In the above example the Java process is given 1GB of heap. Modify the value as best fits to your JVM. However, if the result is that your JVM still dies with OutOfMemoryError, you might still not be able to avoid the manual or Plumbr-assisted analysis described above.

Время на прочтение
3 мин

Количество просмотров 196K

Если вы словили OutOfMemoryError, то это вовсе не значит, что ваше приложение создает много объектов, которые не могут почиститься сборщиком мусора и заполняют всю память, выделенную вами с помощью параметра -Xmx. Я, как минимум, могу придумать два других случая, когда вы можете увидеть эту ошибку. Дело в том, что память java процесса не ограничивается областью -Xmx, где ваше приложение программно создает объекты.

image

Область памяти, занимаемая java процессом, состоит из нескольких частей. Тип OutOfMemoryError зависит от того, в какой из них не хватило места.

1. java.lang.OutOfMemoryError: Java heap space

Не хватает место в куче, а именно, в области памяти в которую помещаются объекты, создаваемые программно в вашем приложении. Размер задается параметрами -Xms и -Xmx. Если вы пытаетесь создать объект, а места в куче не осталось, то получаете эту ошибку. Обычно проблема кроется в утечке памяти, коих бывает великое множество, и интернет просто пестрит статьями на эту тему.

2. java.lang.OutOfMemoryError: PermGen space

Данная ошибка возникает при нехватке места в Permanent области, размер которой задается параметрами -XX:PermSize и -XX:MaxPermSize. Что там лежит и как бороться с OutOfMemoryError возникающей там, я уже описал подробнейшим образом тут.

3. java.lang.OutOfMemoryError: GC overhead limit exceeded

Данная ошибка может возникнуть как при переполнении первой, так и второй областей. Связана она с тем, что памяти осталось мало и GC постоянно работает, пытаясь высвободить немного места. Данную ошибку можно отключить с помощью параметра -XX:-UseGCOverheadLimit, но, конечно же, её надо не отключать, а либо решать проблему утечки памяти, либо выделять больше объема, либо менять настройки GC.

4. java.lang.OutOfMemoryError: unable to create new native thread

Впервые я столкнулся с данной ошибкой несколько лет назад, когда занимался нагрузочным тестированием и пытался выяснить максимальное количество пользователей, которые могут работать с нашим веб-приложением. Я использовал специальную тулзу, которая позволяла логинить пользователей и эмулировать их стандартные действия. На определенном количестве клиентов, я начал получать OutOfMemoryError. Не особо вчитываясь в текст сообщения и думая, что мне не хватает памяти на создание сессии пользователя и других необходимых объектов, я увеличил размер кучи приложения (-Xmx). Каково же было мое удивление, когда после этого количество пользователей одновременно работающих с системой только уменьшилось. Давайте подробно разберемся как же такое получилось.

На самом деле это очень просто воспроизвести на windows на 32-битной машине, так как там процессу выделяется не больше 2Гб.

Допустим у вас есть приложение с большим количеством одновременно работающих пользователей, которое запускается с параметрами -Xmx1024M -XX:MaxPermSize=256M -Xss512K. Если всего процессу доступно 2G, то остается свободным еще коло 768M. Именно в данном остатке памяти и создаются стеки потоков. Таким образом, примерно вы можете создать не больше 768*(1024/512)=1536 (у меня при таких параметрах получилось создать 1316) нитей (см. рисунок в начале статьи), после чего вы получите OutOfMemoryError. Если вы увеличиваете -Xmx, то количество потоков, которые вы можете создать соответственно уменьшается. Вариант с уменьшением -Xss, для возможности создания большего количества потоков, не всегда выход, так как, возможно, у вас существуют в системе потоки требующие довольно больших стеков. Например, поток инициализации или какие-нибудь фоновые задачи. Но все же выход есть. Оказывается при программном создании потока, можно указать размер стека: Thread(ThreadGroup group, Runnable target, String name,long stackSize). Таким образом вы можете выставить -Xss довольно маленьким, а действия требующие больших стеков, выполнять в отдельных потоках, созданных с помощью упомянутого выше конструктора.

Более подробно, что же лежит в стеке потока, и куда уходит эта память, можно прочитать тут.

Конечно, вам может показаться данная проблема слегка надуманной, так как большинство серверов нынче крутиться на 64-битной архитектуре, но все же считаю данный пример весьма полезным, так как он помогает разобраться из каких частей состоит память java-процесса.

Я получаю это сообщение об ошибке, выполняя тесты JUnit:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Я знаю, что такое OutOfMemoryError, но что означает верхний предел GC? Как я могу это решить?

4b9b3361

Ответ 1

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

Это фактически означает, что ваша программа перестает делать какие-либо успехи и всегда работает только с мусорной коллекцией.

Чтобы ваше приложение не впитывало процессорное время без каких-либо действий, JVM выбрасывает этот Error, чтобы у вас была возможность диагностировать проблему.

Редкие случаи, когда я видел это, – это то, где какой-то код создавал тонны временных объектов и тонны объектов с низкой ссылкой в ​​среде с очень ограниченным объемом памяти.

Подробнее о в этой статье (в частности эта часть).

Ответ 2

GC генерирует это исключение, когда слишком много времени тратится на сбор мусора для слишком небольшого возврата, например. 98% времени процессора тратится на GC и восстанавливается менее 2% кучи.

Эта функция предназначена для того, чтобы приложения не работали в течение длительного периода времени, делая небольшие или никакие изменения, потому что куча слишком мала.

Вы можете отключить это с помощью опции командной строки
-XX:-UseGCOverheadLimit

Подробнее здесь

EDIT: похоже, кто-то может набирать быстрее меня:)

Ответ 3

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

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

Если необходимо,

Ответ 4

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

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

java -Xloggc: gc.log GarbageCollector

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

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

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

Ответ 5

Причина ошибки

Превышен лимит накладных расходов 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

Java 7 (JDK 7) сборка мусора и документация по G1

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

Статья о технической сети Oracle для тонкой настройки GC

Ответ 6

Просто немного увеличьте размер кучи, установив эту опцию в

Запустить → Запустить конфигурации → Аргументы → Аргументы VM

-Xms1024M -Xmx2048M

Xms – для минимального предела

Xmx – для максимального предела

Ответ 7

Для меня сработали следующие шаги:

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

    -Xms40m
    -Xmx512m
    

    в

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

Посмотреть здесь

Ответ 8

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

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

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

Ответ 9

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

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

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

Ответ 10

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

dexOptions {
    javaMaxHeapSize "1g"
}

to (Добавить эту строку в gradle)

 dexOptions {
        javaMaxHeapSize "4g"
    }

Ответ 11

Перезагрузка моего MacBook исправила эту проблему для меня.

Ответ 12

Вы также можете увеличить выделение памяти и размер кучи, добавив это в файл gradle.properties:

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

Это не должно быть 2048M и 32g, сделайте его таким большим, как вы хотите.

Ответ 13

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

Ответ 14

Я работаю в Android Studio и столкнулся с этой ошибкой при попытке создания подписанного APK для выпуска.
Мне удалось создать и протестировать отладочную APK без проблем, но как только я захочу создать APK выпуска, процесс сборки будет работать в течение нескольких минут подряд, а затем окончательно завершится с помощью “Ошибка java.lang.OutOfMemoryError: GC превышение верхнего предела”. Я увеличил размеры кучи как для VM, так и для компилятора Android DEX, но проблема не устранена.
Наконец, после многих часов и кружек кофе выяснилось, что проблема была в моем файле buildGradle на уровне приложения. У меня был параметр minifyEnabled для типа сборки релиза, установленного на “false”, и, следовательно, работа с продуктами 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
    }
}

//...

Ответ 15

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

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

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

idea64.exe.vmoptions

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

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

Вот и все!

Ответ 16

Я использую apache-tomcat-8.5.37. Я сталкиваюсь с той же ошибкой

java.lang.outofmemoryerror: превышен предел накладных расходов gc

Я прочитал выше о решении поговорка

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

Это решение сработало для кого-то? Нужен совет по устранению проблемы.

Ответ 17

Решено:
Просто добавьте
 org.gradle.jvmargs=-Xmx1024m
в
 gradle.properties
и если он не существует, создайте его.

Ответ 18

Описание размера кучи Java (xms, xmx, xmn)

-Xms size in bytes

Example : java -Xms32m

Устанавливает начальный размер кучи Java.
Размер по умолчанию – 2097152 (2 МБ).
Значения должны быть кратны и превышать 1024 байта (1 КБ).
(Флаг -server увеличивает размер по умолчанию до 32M.)

-Xmn size in bytes

Example : java -Xmx2m

Устанавливает начальный размер кучи Java для поколения Eden.
Значением по умолчанию является 640K.
(Флаг -server увеличивает размер по умолчанию до 2M.)

-Xmx size in bytes

Example : java -Xmx2048m

Устанавливает максимальный размер, до которого может расти куча Java.
Размер по умолчанию составляет 64M.
(Флаг -server увеличивает размер по умолчанию до 128M.)
Максимальный предел кучи составляет около 2 ГБ (2048 МБ).

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

При настройке размера кучи Java вы должны указать аргумент памяти, используя одну из букв “m” или “M” для MB, или “g” или “G” для GB. Ваши настройки не будут работать, если вы укажете “МБ” или “ГБ”. Допустимые аргументы выглядят так:

-Xms64m или -Xms64m
-Xmx1G или -Xmx1G
Можно также использовать 2048 МБ, чтобы указать 2 ГБ
Кроме того, убедитесь, что вы просто используете целые числа при указании аргументов. Использование -Xmx512m является допустимым параметром, но -Xmx0.5g вызовет ошибку.

Эта ссылка может быть полезна для кого-то.

Ответ 19

В Netbeans может оказаться полезным создать максимальный размер кучи. Перейдите в Run = > Set Project Configuration = > Customize. В поле “Выполнить” всплывающее окно перейдите к опции VM, заполните -Xms2048m -Xmx2048m. Это может решить проблему размера кучи.

Добавить комментарий