java.lang.OutOfMemoryError: Превышен лимит накладных расходов GC

Question

Я получаю эту ошибку в программе, которая создает несколько (сотни тысяч) объектов HashMap с несколькими (15-20) текстовыми записями каждый. Эти строки должны быть собраны (без разбивки на меньшие суммы) перед отправкой в ​​базу данных.

Согласно Sun, ошибка возникает "если слишком много времени тратится на сборку мусора: если на сборку мусора уходит более 98% общего времени и восстанавливается менее 2% кучи, OutOfMemoryError быть брошенным. ".

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

• Увеличение размера кучи через "-Xmx1024m" (или более) или
• Полностью отключить проверку ошибок через "-XX: -UseGCOverheadLimit".

Первый подход работает нормально, второй заканчивается другим java.lang.OutOfMemoryError, на этот раз о куче.

Итак, вопрос: есть ли программная альтернатива этому для конкретного варианта использования (то есть, несколько небольших объектов HashMap)? Например, если я использую метод clear () HashMap, проблема исчезнет, ​​но и данные, хранящиеся в HashMap! : -)

Эта проблема также обсуждается в связанной теме в StackOverflow.

Answer 1

Устраните утечки памяти в вашем приложении с помощью инструментов профиля, таких как eclipse MAT или VisualVM

В JDK 1.7.x или более поздних версиях используйте G1GC, , который тратит 10% на сборку мусора, в отличие от 2% в других алгоритмах GC. Помимо установки кучи памяти с помощью -Xms1g -Xmx2g, попробуйте `

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

Посмотрите статью oracle для тонкой настройки этих параметров.

Некоторые вопросы, связанные с G1GC в SE:

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

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

Стратегия агрессивного сбора мусора

Answer 2

Для этого используйте приведенный ниже код в файле gradle вашего приложения при закрытии Android.

dexOptions { javaMaxHeapSize "4g" }

Answer 3

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

Answer 4

В случае ошибки:

"Внутренняя ошибка компилятора: java.lang.OutOfMemoryError: Превышен предел издержек GC при java.lang.AbstractStringBuilder"

увеличениепространство кучи Java до 2 ГБ, т. е. -Xmx2g.

Answer 5

В моем случае решением было увеличение памяти с помощью опции -Xmx.

Я прочитал файл 10g в Java, и каждый раз получал одну и ту же ошибку.Это произошло, когда значение в столбце RES в команде top достигло значения, установленного в опции -Xmx.Затем, увеличив память с помощью опции -Xmx, все прошло нормально.

Был и другой момент.Когда я установил JAVA_OPTS или CATALINA_OPTS в своей учетной записи и снова увеличил объем памяти, я получил ту же ошибку.Затем я напечатал значение этих переменных окружения в моем коде, которые дали мне значения, отличные от установленных.Причина заключалась в том, что Tomcat был корнем этого процесса, а затем, поскольку я не был неудачником, я попросил администратора увеличить память в catalina.sh в Tomcat.

Answer 6

Это помогло мне избавиться от этой ошибки. Эта опция отключает -XX: + DisableExplicitGC