2009-11-20 11 views
6

Al cargar todas las pruebas unitarias en un paquete, la tarea make arroja un java.lang.OutOfMemoryError: error de espacio en el montón de Java.JUnit java.lang.OutOfMemoryError al ejecutar todas las pruebas en un paquete

Si ejecuto todas las pruebas en cada subpaquete, todas las pruebas se cargan y completan bien. Solo cuando intento ejecutar todas las pruebas en el paquete principal, aparece el error OOM.

No creo que este problema deba resolverse ajustando los parámetros de VM. Traté de aumentar el tamaño máximo de montón y permanente, y no resolvió el problema.

Esto me lleva a creer que hay algún problema con la recolección de basura entre las pruebas de carga en diferentes paquetes, o que hay una carga de clase demasiado ansiosa.

¿Existe una configuración de JUnit que podría resolver estos problemas, o el problema tendrá que resolverse cambiando o agregando código en los casos de prueba?

+0

¿Estás seguro de que no tienes un consumo significativo de memoria en la estática de tus clases de prueba o en estadísticas alcanzadas por tus clases de prueba? – bmargulies

+1

¿cómo modificó realmente los parámetros de VM? Intente confirmar que han sido configurados correctamente por los métodos en java.lang.Runtime – Bozho

+0

No estoy seguro sobre el consumo de memoria de la estática, pero definitivamente lo investigaré. En cuanto a los parámetros de VM, probé estos: -Xmx512m -XX: PermSize = 128m -XX: MaxPermSize = 512m pero aumentarlos no ayudó a resolver el error OOM. –

Respuesta

3

El GC se ejecuta cuando la CPU tiene tiempo libre o la memoria libre es baja. Si tus pruebas fallan, es posible que tengas una pérdida de memoria en alguna parte. (Sí, existen en Java también)

Busque referencias circulares y clases/variables estáticas.Theses son razones comunes de IIRC para pérdidas de memoria. También deberías echarle un vistazo a jconsole.

9

Debe establecer todos los campos de las clases de prueba en null en tearDown().

La razón es que JUnit instancia una instancia de la clase de prueba por prueba. Guarda esa instancia durante todo el tiempo para guardar los resultados de la prueba (éxito, falla, seguimiento de la pila). Entonces, si usa campos, se quedarán y se le agotará la memoria.

+0

Genial, voy a probar esta solución primero. –

+0

Desafortunadamente, esto no resolvió el problema. no se llama a tearDown() solo después de que se hayan cargado todas las clases y se comiencen a ejecutar las pruebas? El error OOM que estoy viendo ocurre durante la tarea Make, incluso antes de que las pruebas comiencen a ejecutarse. –

+0

No, se llama a tearDown después de cada prueba individual. Pero me perdí "en la tarea Make". ¿De qué te hace la tarea estás hablando? ¿Estás usando Ant? ¿O hacer GNU? –

4

Tuve un problema similar con TestNG y lo remonté a la cantidad de información de registro que generaba en la consola. Una vez que reduje esto, pude ejecutar mi suite de pruebas sin problemas de memoria.

+0

Observó este mismo problema al ejecutar pruebas con JUnit y maven. El nivel de registro estaba en DEPURAR y creando errores OOM, después de cambiar a ERROR los problemas desaparecieron. – Rich

Cuestiones relacionadas