spark - java.lang.outofmemoryerror: gc overhead limit exceeded tomcat

Error java.lang.OutOfMemoryError: límite de sobrecarga del GC excedido

Question

Recibo este mensaje de error mientras ejecuto mis pruebas JUnit:

java.lang.OutOfMemoryError: GC overhead limit exceeded

Sé lo que es un OutOfMemoryError , pero ¿qué significa el límite de sobrecarga de GC? ¿Como puedo resolver esto?

Answer 1

Causa del error

Se excedió el límite de sobrecarga del GC "indica que el recolector de basura se está ejecutando todo el tiempo y el programa Java está avanzando muy lentamente.

Después de una recolección de basura, si el proceso Java está gastando más de aproximadamente el 98% de su tiempo haciendo recolección de basura y si está recuperando menos del 2% del montón y ha estado haciendo hasta ahora los últimos 5 (constante de tiempo de compilación) basura consecutiva colecciones, luego se lanza un java.lang.OutOfMemoryError

1. Aumente el tamaño del montón si el montón actual no es suficiente.
2. Si aún recibe este error después de aumentar la memoria del montón, use herramientas de creación de perfiles de memoria como MAT ( herramienta de análisis de memoria), Visual VM, etc. y corrija las fugas de memoria.
3. Actualice la versión JDK a la última versión (1.8.x) o al menos 1.7.x y use el algoritmo G1GC. . El objetivo de rendimiento del G1 GC es el 90% del tiempo de aplicación y el 10% del tiempo de recolección de basura

4. Además de configurar la memoria del montón con - Xms1g -Xmx2g , intente

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

Echa un vistazo a algunas preguntas más relacionadas con G1GC

Recolección de basura Java 7 (JDK 7) y documentación sobre G1

Recolección de basura Java G1 en producción.

Artículo de la red Oracle para el ajuste de GC.

Answer 2

El GC lanza esta excepción cuando se pasa demasiado tiempo en la recolección de basura por muy poco rendimiento, por ejemplo. El 98% del tiempo de CPU se gasta en GC y se recupera menos del 2% del montón.

Esta característica está diseñada para evitar que las aplicaciones se ejecuten durante un período prolongado de tiempo mientras se avanza poco o nada porque el montón es demasiado pequeño.

Puede desactivar esto con la opción de línea de comando -XX:-UseGCOverheadLimit

Más información here

EDITAR: parece que alguien puede escribir más rápido que yo :)

Answer 3

En Netbeans, puede ser útil diseñar un tamaño máximo de almacenamiento dinámico. Vaya a Ejecutar => Establecer configuración del proyecto => Personalizar . En la ventana Ejecutar de su ventana emergente, vaya a Opción de VM , complete -Xms2048m -Xmx2048m . Se podría resolver el problema del tamaño del montón.

Answer 4

Este mensaje significa que, por alguna razón, el recolector de basura está tomando una cantidad de tiempo excesiva (por defecto, el 98% de todo el tiempo de CPU del proceso) y recupera muy poca memoria en cada ejecución (por defecto, el 2% del montón).

Esto efectivamente significa que su programa deja de hacer progresos y está ocupado ejecutando solo la recolección de basura en todo momento.

Para evitar que su aplicación consuma tiempo de CPU sin hacer nada, la JVM lanza este Error para que tenga la oportunidad de diagnosticar el problema.

Los casos raros en los que he visto que esto suceda es cuando algún código creaba toneladas de objetos temporales y toneladas de objetos con referencias débiles en un entorno que ya tenía mucha memoria.

Echa un vistazo a este artículo para más detalles (específicamente esta parte ).

Answer 5

Estoy trabajando en Android Studio y encontré este error al intentar generar un APK firmado para su lanzamiento. Pude compilar y probar un APK de depuración sin ningún problema, pero tan pronto como quise compilar un APK de versión, el proceso de compilación se ejecutaría durante minutos y finalmente terminaría con el "Error java.lang.OutOfMemoryError: GC límite de sobrecarga excedido ". Aumenté el tamaño del montón tanto para la VM como para el compilador de DEX de Android, pero el problema persistió. Finalmente, después de muchas horas y tazas de café, se descubrió que el problema estaba en mi archivo ''build.gradle'' a nivel de la aplicación. Tenía el parámetro ''minifyEnabled'' para el tipo de compilación del lanzamiento establecido en ''false'', por lo tanto ejecutando las cosas Proguard en el código que no ha pasado por el proceso de reducción de código (consulte https://developer.android.com/studio/build/shrink-code.html ). Cambié el parámetro ''minifyEnabled'' a ''true'' y la versión de lanzamiento se ejecutó como un sueño :)

En resumen, tuve que cambiar el archivo ''build.gradle'' de mi nivel de aplicación de: // ...

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
}
}
//...

a

 //...
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
}
}
//...

Answer 6

Lo siguiente funcionó para mí. Solo agrega el siguiente fragmento de código:

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

Answer 7

Necesita aumentar el tamaño de la memoria en Jdeveloper y vaya a 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**
)

y

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 8

Normalmente es el código. Aquí hay un ejemplo simple:

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

Usando java 1.6.0_24-b07 en un Windows7 32 bit.

java -Xloggc: gc.log GarbageCollector

Entonces mira gc.log

• Activado 444 veces utilizando el método BAD
• Activado 666 veces usando el método PEOR
• Activado 354 veces usando el método MEJOR

Ahora, esta no es la mejor prueba ni el mejor diseño, pero cuando se enfrenta a una situación en la que no tiene más remedio que implementar un bucle de este tipo o cuando se trata de un código existente que se comporta mal, puede reducir la reutilización de objetos en lugar de crear nuevos. el número de veces que el recolector de basura se interpone en el camino ...

Answer 9

Para aumentar el tamaño del montón en IntelliJ IDEA, siga las siguientes instrucciones. Funcionó para mí.

Para los usuarios de Windows,

Vaya a la ubicación donde está instalado IDE y busque lo siguiente.

idea64.exe.vmoptions

Edite el archivo y agregue lo siguiente.

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

Eso es !!

Answer 10

Para mí, los siguientes pasos funcionaron:

1. Abra el archivo eclipse.ini

2. Cambio

   -Xms40m
   -Xmx512m

   a

   -Xms512m
   -Xmx1024m

3. Reiniciar Eclipse

Mira aquí

Answer 11

Si está seguro de que no hay pérdidas de memoria en su programa, intente:

1. Aumente el tamaño del montón, por ejemplo, -Xmx1g .
2. Habilite el colector de pausa baja concurrente -XX:+UseConcMarkSweepGC .
3. Reutilizar objetos existentes cuando sea posible para guardar algo de memoria.

Si es necesario, la verificación de límites se puede desactivar agregando la opción -XX:-UseGCOverheadLimit a la línea de comandos.

Answer 12

Solo aumenta un poco el tamaño del montón configurando esta opción en

Ejecutar → Ejecutar configuraciones → Argumentos → Argumentos de VM

-Xms1024M -Xmx2048M

Xms - para límite mínimo

Xmx - para el límite máximo

Answer 13

aumente javaMaxHeapsize en su archivo build.gradle (Module: app)

dexOptions {
javaMaxHeapSize "1g"
}

a (Añade esta linea en gradle)

 dexOptions {
javaMaxHeapSize "4g"
}

Answer 14

prueba esto

abrir el archivo build.gradle

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