java - generate - jstack thread state

¿Cómo afecta jstack-F a un proceso Java en ejecución?

Question

Estoy intentando diagnosticar un problema donde una aplicación web de Java que estoy usando (Jenkins) deja de responder. Si ejecuto jstack sin el indicador -F , no me da nada, pero si pongo el indicador para forzar un volcado de subprocesos no solo obtengo un resultado, sino que la aplicación comienza a responder y continúa como si no hubiera pasado nada. hasta que finalmente deja de responder de nuevo.

¿Qué hace la jstack -F que afectaría a una JVM en ejecución y causaría que una aplicación que no responde comience a responder nuevamente?

Answer 1

Puedes ver la fuente de jstack here . El argumento -F cambia la forma en que jstack se conecta a jvm. Con -F (o -m) JStack se conecta a jvm mediante la interfaz del depurador de Java. Si se especifica un pid, JStack se conecta con el conector de conexión PID de SA que dice:

El proceso de depuración no debe haberse iniciado en modo de depuración (es decir, con -agentlib: jdwp o -Xrunjdwp). Es permisible que el proceso se cuelgue .

No sé por qué causaría que una aplicación que no responde comience a responder de nuevo, pero el enlace de arriba también dice:

El proceso se suspende cuando este conector se conecta y se reanuda cuando este conector se desconecta.

Esto puede tener un efecto.

Answer 2

jstack -F -l pid es similar a (asumiendo que el directorio de trabajo es JAVA_HOME)

bin/java -Dsun.jvm.hotspot.debugger.useWindbgDebugger  -Dsun.jvm.hotspot.debugger.useProcDebugger  -cp lib/sa-jdi.jar;lib/tools.jar  sun.tools.jstack.JStack -F -l pid

y en el código sun.tools.jstack.JStack

   if (arg.equals("-F")) {
       useSA = true;
   }
   .....
   // now execute using the SA JStack tool or the built-in thread dumper
   if (useSA) {
       // parameters (<pid> or <exe> <core>
       ...
       runJStackTool(mixed, locks, params);
   } else {
       // pass -l to thread dump operation to get extra lock info
       String pid = args[optionCount];
        ...
       runThreadDump(pid, params);
    }

y como se pasa -F, se ejecuta runStockTool para cargar sun.jvm.hotspot.tools.JStack, tiene el mismo efecto de invocar directamente

bin/java -Dsun.jvm.hotspot.debugger.useWindbgDebugger  -Dsun.jvm.hotspot.debugger.useProcDebugger  -cp lib/sa-jdi.jar;lib/tools.jar  sun.jvm.hotspot.tools.JStack pid

y sun.jvm.hotspot.tools.JStack llamará sun.jvm.hotspot.bugspot.BugSpotAgent attach -> ir -> método setupVM

Tal vez el código de abajo es la magia

       jvmdi = new ServiceabilityAgentJVMDIModule(debugger, saLibNames);
       if (jvmdi.canAttach()) {
           jvmdi.attach();
           jvmdi.setCommandTimeout(6000);
           debugPrintln("Attached to Serviceability Agent''s JVMDI module.");
           // Jog VM to suspended point with JVMDI module
           resume();
           suspendJava();
           suspend();
           debugPrintln("Suspended all Java threads.");
       }

suspenderá todos los hilos de Java en el proceso de destino. Si su aplicación se cuelga por inanición de subprocesos, la llamada al método de suspensión puede relajarlos.