Mis técnicas de depuración de Java favoritas

Este artículo trata sobre técnicas que he usado para depurar codeBases de varios tipos, como:

  1. CodeBase con alta naturaleza concurrente.
  2. CodeBase con una gran cantidad de bibliotecas propietarias (no admitidas).
  3. CodeBase con una gran cantidad de código obsoleto / no deseado.
  4. CodeBase con pérdidas de memoria.
  5. CodeBase donde cada JVM puede comunicarse con todas las demás JVM.

Así que veámoslos uno por uno.

CodeBase con alta naturaleza concurrente.

Puede suceder que para atender una solicitud, JVM use muchos subprocesos, por ejemplo:

Req -> tomcatThread-1 -> executorThread-2 -> BizThread-3->…`

Digamos que encontramos que la excepción viene en BizThread-3. Ahora, como depurador, queremos comprender el flujo de solicitudes. Pero stacktrace no podrá proporcionar el flujo de solicitud completo (por ejemplo, qué sucedió en ejecutorThread-2 y qué sucedió en tomcatThread-1 y así sucesivamente).

Técnica 1.1: Escriba un agente java personalizado que se utilizará para agregar de manera efectiva log.debug()al inicio y al final de cada método de ciertos paquetes java. Esto nos dará una idea de cómo se llama a todos.

Técnica 1.2: En ciertos marcos, si es compatible, use AOP para proxy todos los métodos y agregue de manera efectiva log.debug().

CodeBase con una gran cantidad de bibliotecas propietarias (no admitidas).

A veces nos encontramos en una situación en la que, después de horas de depuración, detectamos el problema de que la biblioteca xyz-gov-secret se está comportando mal y esta biblioteca ahora no es compatible.

Técnica 2.1: arremangarse e instalar eclipse-decompilery sumergirse en la base del código.

CodeBase con una gran cantidad de código obsoleto / no deseado.

Este es uno clásico: a veces nos encontramos con un método de más de 500 líneas con toneladas de if-else obsoleto. Ahora, ¿cómo averiguamos cuál es el flujo de código para una llamada en particular, qué if-else vamos a usar y cuál es el código muerto?

Técnica 3.1: Podemos utilizar una herramienta llamada agente jacoco . Recopila los detalles de ejecución durante el tiempo de ejecución y puede codificar con colores el código en eclipse.

Básicamente, es la misma herramienta, generalmente utilizada para analizar la cobertura de código por JUnit Test.

CodeBase con pérdidas de memoria.

Cada desarrollador tiene un día en el que, en su sistema local, todo va bien, en producción OutOfMemory :(

Técnica 4.1:JVM proporciona técnicas para capturar volcados de pila en caso de outOfMemory.

Agregue lo siguiente como argumento al iniciar la JVM

-XX: + HeapDumpOnOutOfMemoryError . Esto capturará el volcado de pila y lo colocará en un archivo, que puede usarse para analizar qué está consumiendo la memoria.

Técnica 4.2: También puede realizar el volcado de montón / volcado de subprocesos de una JVM en ejecución utilizando jProfiler / Jvisiualvm.

CodeBase donde cada JVM puede comunicarse con todas las demás JVM.

Cuando se le arroja a un entorno distribuido de espagueti, resulta difícil rastrear el flujo de solicitudes.

Técnica 5.1: puede utilizar herramientas como Wireshark . Wireshark captura los datos de la red y los representa en una interfaz de usuario agradable. Luego puede ver la solicitud / respuesta HTTP que fluye a través del sistema

Menciones honoríficas

Técnica 6.1: En un entorno de un solo subproceso, inserte intencionalmente

try catch para conocer rápidamente el stacktrace.

try { throw new RuntimeException(); } catch(Exception e){ e.printStackTrace(); }

Técnica 6.2: Usar un punto de interrupción de eclipse o usar un punto de interrupción condicional.

Técnica 6.3: //en.wikipedia.org/wiki/Rubber_duck_debugging

Motivación del artículo: aprendizaje en equipo / intercambio de conocimientos.