Comenzar con el Perfil de Asignaciones

Otros idiomas:

A menudo nos encontramos en situaciones donde el código no funciona correctamente, y no tenemos idea de por dónde empezar a investigar.

¿No podemos simplemente mirar el código hasta que la solución eventualmente nos llegue? Claro, pero este método probablemente no funcionará sin un conocimiento profundo del proyecto y mucho esfuerzo mental. Un enfoque más inteligente sería usar las herramientas que tienes a mano. Pueden indicarte la dirección correcta.

En esta publicación, veremos cómo podemos perfilar las asignaciones de memoria para resolver un problema en tiempo de ejecución.

El problema

Comencemos clonando el siguiente repositorio:

Después de trabajar durante algún tiempo, la animación se congela sin ninguna indicación de cuál es la causa. El programa a veces puede lanzar un error OutOfMemoryError, cuyo stack trace no nos dice nada sobre el origen del problema.

No hay una forma segura de decir cómo se manifestará exactamente el problema. Lo interesante de este bloqueo de animación es que aún podemos usar el resto de la interfaz de usuario después de que ocurra.

Note: Utilicé Amazon Corretto 11 para ejecutar esta aplicación. El resultado puede variar en otras JVMs o incluso en la misma JVM si utiliza una configuración diferente.

El depurador

Parece que tenemos un error. ¡Intentemos usar el depurador! Lanza la aplicación en modo de depuración, espera hasta que la animación se congele, luego presiona

Desafortunadamente, esto no nos dijo mucho porque todos los hilos involucrados en la fiesta del loro están en estado de espera. Inspeccionar sus pilas no da ninguna indicación de por qué ocurrió el bloqueo. Claramente, necesitamos probar otro enfoque.

Monitorizar el uso de recursos

Dado que estamos obteniendo un error OutOfMemoryError, un buen punto de partida para el análisis es CPU and Memory Live Charts. Permiten visualizar el uso de recursos en tiempo real para los procesos que están en ejecución. Vamos a

En efecto, vemos que el uso de memoria va aumentando continuamente antes de alcanzar un plateau. Este es precisamente el momento en que la animación se cuelga, y después de eso parece que se queda colgada para siempre.

Esto nos da una pista. Por lo general, la curva de uso de memoria tiene forma de sierra: el gráfico sube cuando se asignan nuevos objetos y periódicamente baja cuando la memoria se recupera después de recoger los objetos no utilizados. Puedes ver un ejemplo de un programa que funciona normalmente en la imagen de abajo:

El uso de la memoria no disminuye después de que nuestra aplicación llega al plateau, incluso si solicitamos manualmente que libere algo de memoria. Esto respalda nuestra hipótesis de que no hay objetos elegibles para la recolección de basura.

Una solución ingenua sería simplemente agregar más memoria. Para ello, añade la opción VM -Xmx500m a la configuración de ejecución.

Perfil de asignación

Dado que sabemos que nuestra aplicación nunca tiene suficiente memoria, es razonable sospechar una fuga de memoria y analizar su uso de memoria. Para ello, podemos recoger un volcado de memoria utilizando la opción VM -XX:+HeapDumpOnOutOfMemoryError. Este es un enfoque perfectamente aceptable para inspeccionar el heap; sin embargo, no señalará el código responsable de crear estos objetos.

Podemos obtener esta información de una instantánea del perfil: no sólo proporcionará estadísticas sobre los tipos de los objetos, sino que también revelará los seguimientos de pila correspondientes a cuando fueron creados. Aunque este es un caso de uso un poco inconvencional para el perfil de asignación, nada nos impide usarlo para identificar el problema.

Vamos a

Hay varias vistas disponibles para los datos recogidos. En este tutorial, utilizaremos el . Los elementos más anchos representan los tipos más masivamente asignados durante el período de perfilamiento.

Es importante señalar aquí que muchas asignaciones no necesariamente indican un problema. Una fuga de memoria ocurre sólo si los objetos asignados no son recogidos por el recolector de basura. Mientras que el perfil de asignación no nos dice nada sobre la recolección de basura, todavía puede darnos pistas para la investigación posterior.

Hacer clic en el frame nos lleva al código fuente del método correspondiente:

public void updateParrot() {

    currentParrotIndex = (currentParrotIndex + 1) % parrots.size();

    BufferedImage baseImage = parrots.get(currentParrotIndex);

    State state = new State(baseImage, getHue());

    BufferedImage coloredImage = cache.computeIfAbsent(state, (s) -> Recolor.recolor(baseImage, hue));

    parrot.setIcon(new ImageIcon(coloredImage));

}

Parece que updateParrot() toma una imagen base y luego la recolorea. Para evitar trabajo extra, la implementación primero intenta recuperar la imagen de alguna cache. La clave para recuperarla es un objeto State, cuyo constructor toma una imagen base y un matiz:

public State(BufferedImage baseImage, int hue) {

    this.baseImage = baseImage;

    this.hue = hue;

}

Analizar el flujo de datos

Usando el analizador estático incorporado, podemos rastrear el rango de valores de entrada para la llamada al constructor de State. Haz clic con el botón derecho en el argumento del constructor baseImage, luego desde el menú, selecciona Analyze | Data Flow to Here.

Son diez imágenes base que corresponden a las posibles posiciones del loro. Bueno, ¿qué hay del argumento del constructor hue?

la aplicación objetivo.

Pongamos un punto de interrupción en la acción de actualización y añadamos una condición para que solo suspenda la aplicación cuando el tamaño de la cache exceda los 1000 elementos.

en cache nos lleva a su sitio de declaración:

private static final Map<State, BufferedImage> cache = new HashMap<>();

Si comprobamos la documentación de HashMap, encontraremos que su implementación se basa en los métodos equals() y hashcode(), y el tipo que se utiliza como clave tiene que sobrescribirlos correctamente. Comprobémoslo. y seleccione equals() and hashcode(). Acepte las sugerencias y haga clic en Next hasta que los métodos aparezcan en el caret.

@Override

public boolean equals(Object o) {

    if (this == o) return true;

    if (o == null || getClass() != o.getClass()) return false;

    State state = (State) o;

    return hue == state.hue && Objects.equals(baseImage, state.baseImage);

}



@Override

    public int hashCode() {

    return Objects.hash(baseImage, hue);

}

Verificar la corrección

Reiniciemos la aplicación y veamos si las cosas han mejorado. Una vez más, podemos usar CPU and Memory Live Charts para eso:

¡Eso es mucho mejor!

Resumen

En esta publicación, analizamos cómo podemos comenzar con los síntomas generales de un problema y luego, utilizando nuestro razonamiento y la variedad de herramientas disponibles para nosotros, reducir el alcance de la búsqueda paso a paso hasta encontrar la línea de código exacta que está causando el problema. ¡Más importante aún, nos aseguramos de que la fiesta del loro continúe sin importar qué!

Como siempre, estaré encantado de escuchar tus comentarios! ¡Feliz perfilado!