Acabo de usar Jstack para resolver el problema de un punto muerto de proceso; de hecho, lo he resuelto hace mucho tiempo, y sé la razón, pero no he encontrado la ubicación del punto muerto, por lo que no estoy muy dispuesto a hacerlo.
El proceso es más o menos como sigue:
(0) Requisitos ambientales, JDK 1.6 y superior
(1) Primero encuentre el PID del proceso. En Windows, abra el Administrador de procesos y ordenelo por su nombre. Puede encontrar un proceso llamado javaw.exe (los procesos de máquina virtual Java se llaman javaw.exe). Debe encontrar qué proceso es su proceso, recuerde la lista de procesos actual y luego reiniciar su proceso. El que ha sido renovado por el PID es su proceso.
(2) Ejecutar bajo CMD: Jstack Pid, Jstack escribirá una serie de información en la consola
(3) Analice la información anterior
Ejemplo:
La información de Jstack para mi pregunta es la siguiente:
C:/documentos y configuraciones/usuario> jstack 66522012-06-07 21: 32: 02Full hilo volcado java hotspot (tm) cliente vm (16.3-b01 modo mixto, compartir): "hilo-1" daemon prio = 6 tid = 0x003010c00 nid = 0xcdc esperando la entrada de monitor [0x03339f000] java.lang.thread.state: bloqueado (en el monitor de objeto) en org.apache.commons.net.telnet.telnetinputstream .__ read (telnetinputstream.java:122) - esperando para bloquear <0x22942280> (a org.apache.commons.net.ftp.ftpclient) at at at at at at at at at at at at at at at at at at at at at at at at at at at at to org.apache.commons.net.telnet.telnetinputstream.run (telnetinputstream.java:535) en java.lang.thread.run (hild.java:619) "Framework Event Desaptador" Daemon Prio = 6 Tid = 0x030400 nid = 0x998 en Object.wait () [) [) [) [0x034f000] java.lang.thread.state: Waiting (en el monitor de objeto) en java.lang.object.wait (método nativo) - esperando en <0x228fa800> (a org.eclipse.osgi.framework.eventmgr.eventmanager $ eventThread) en java.lang.object.wait (objeto.java:485) org.eclipse.osgi.framework.eventmgr.eventmanager $ eventthread.getNextEvent (eventManager.java:400) - bloqueado <0x228fa800> (a org.eclipse.osgi.framework.eventmgr.eventmanager $ eventthread) en org.eclipse.osgi.framework.eventmgr.eventmanager $ eventthread.run (eventManager.java:336) "Inicie el nivel de eventos" Daemon Prio = 6 tid = 0x02fcf400 nid = 0x2638 en object.wait () [0x032de000] java.lang.thread.thread.state java.lang.object.wait (método nativo) - Esperando <0x2295db48> (a [i) en java.lang.object.wait (objeto.java:485) en org.apache.commons.net.telnet.telnetinputStream.read (teletinputstream.java:339) - bloqueado <0x2295295295295295 (a [i) en org.apache.commons.net.telnet.telnetinputStream.read (telnetinputstream.java:466) en java.io.bufferedinputStream.read1 (bufferedinputStream.java:256) en java.io.BufferedinStream.Read (buffeDinputinputer.Java:317) <0x2295fe18> (a java.io.bufferedinputstream) en Sun.nio.cs.streamdecoder.readbytes (streamdecoder.java:264) en Sun.nio.cs.streamdecoder.implread (streamdecoder.java:306) AT Sun.nio.cs.streamdecoder.read (streamDecoder.java:158) - bloqueado <0x22961f88> (un java.io.inputstreamreader) en java.io.inputstreamreader.read (inputStreamReader.Java:167) en java.io.bufferedReader.fill (bufferedreader.java:136) en java.io.bufferedreader.readline (bufferedreader.java:299) - bloqueado <0x22961f88> (a java.io.inputsteamreader) en java.io.iM org.apache.commons.net.ftp.ftp .__ getRreply (ftp.java:264) en org.apache.commons.net.ftp.ftp._connectaction_ (ftp.java:335) en org.apache.commons.net.ftp.ftpclient._connectation org.apache.commons.net.socketclient.connect (Socketclient.java:163) en com.mycompany.dc.ftp.client.ftpclientiMpl.connect (ftpclientiMpl.java:75) - bloqueado <0x22942280> (a org.apache.commons.net.ettpclient) com.mycompany.dc.ftp.client.ftpclientfactoryimpl.getclient (ftpclientFactoryImpl.java:35) - bloqueado <0x228f9310> (a java.lang.object) en ftpclienttest.activator.start (activador.Java:43) en org.eclipse.osgi.framework.internal.core.bundlecontextimpl $ 1.run (bundlecontextimpl.java:711) en java.security.accesscontroller.doprivileged (método nativo) AT org.eclipse.osgi.framework.internal.core.bundlecontextImpl.startactivator (bundLecontextImpl.java:702) en org.eclipse.osgi.framework.internal.core.bundlecontextImpl.start (bundlecontEntEmpl.Java:683) org.eclipse.osgi.framework.internal.core.bundlehost.startworker (bundlehost.java:381) en org.eclipse.osgi.framework.internal.core.abstractbundle.resume (abstractbundle.Java:389) en org.eclipse.osgi.framework.internal.core.framework.resumeBundle (framework.java:1131) en org.eclipse.osgi.framework.internal.core.startlevelmanager.resumeBundles (startlevelmanager.Java:559) en org.eclipse.osgi.framework.internal.core.startlevelvelmanager.ResumeBundles (SuptlevelManager.Java:544) en org.eclipse.osgi.framework.internal.core.startlevelmanager.incfwsl (startlevelmanager.Java:457) At org.eclipse.osgi.framework.internal.core.startlevelmanager.dosetStartLevel (startlevelmanager.java:243) - bloqueado <0x27e68d70> (un java.lang.Object) AT org.eclipse.osgi.framework.internal.core.startlevelvelmanager.dispatchevent (startlevelvelmanager.java:438) en org.eclipse.osgi.framework.internal.core.startlevelmanerer.dispatchevent (startlevelmanager.Java:1) en org.eclipse.osgi.framework.eventmgr.eventmanager.dispatchevent (eventManager.java:230) en org.eclipse.osgi.framework.eventmgr.eventManager $ eventthread.run (eventManager.Java:340) "Badlwork activo" prio = 6 tid = 0x02ff11800 nid = 0x1818181800 nid = 0x181818181800 nid. en object.wait () [0x0328f000] java.lang.thread.state: timed_waiting (en el monitor de objeto) en java.lang.object.wait (método nativo) - esperando en <0x27e657770> (a org.eclipse.osgi.framework.internal.framework) ATT) ATT) ATT) ATT) ATT) ATT) AT org.eclipse.osgi.framework.internal.core.framework.run (framework.java:1817) - bloqueado <0x27e65770> (a org.eclipse.osgi.framework.internal.core.corework) en java.lang.thread.run (hilt.java:69) prio = 6 tid = 0x03005400 nid = 0x225c esperando en la condición [0x0323f000] java.lang.thread.state: timed_waiting (durmiendo) en java.lang.thread.sleep (método nativo) en org.eclipse.osgi.framework.internal.core.frameworkconsole.runconsole (frameworkconsole.java:125) en org.eclipse.osgi.framework.internal.core.frameworkconsole.run (frameworkconsole.java:104) en java.lang.thread.run (Thread.java:619) "Detector de memoria baja" prio = 6 tid = 0x02c09800 nid = 0x1d68 runnable [0x00000000000] java.lang.thread.state: runnable "compilerthread0" demoemon prio = 10 tid = 0x02c03000 neid = 0x244c4 de espera = 0x24 de espera = 0x24 de espera = 0x24 ida condición [0x00000000000] java.lang.thread.state: runnable "adjunte oyorer" Daemon prio = 10 tid = 0x02c01800 nid = 0x1138 esperando en condición [0x00000000000] java.lang.thread.state: runnable "despachador de señal" prio = 10 tid = 0x02c20c00 nid = 0x18ac [0x00000000000] java.lang.thread.state: runnable "finalizer" demoemon prio = 8 tid = 0x02bc0400 nid = 0x11ac en object.wait () [0x02d8f000] java.lang.thread.state: espera (en el monitor de objetos) en java.lang.object.wait (método nativo) - Esperando <0x27d5e5c8> (a java.lang.ref.referenceue $ bloqueo) en java.lang.ref.referenceue.remove (referenceue.java:118) - bloqueado <0x27d5e5c8> (un java.lang.ref.referenceue $ bloqueo) AT java.lang.ref.referenceue.remove (referencequeue.java:134) en java.lang.ref.finalizer $ finalizerThread.run (finalizador.java:159) "Handler de referencia" Daemon Prio = 10 Tid = 0x02Bb800 nid = 0x9cc en Object.Wait () [0x02d3f000] java.lang.thread.state: Waiting (en el monitor de objeto) en java.lang.object.wait (método nativo) - esperando en <0x27d5e650> (un java.lang.ref.reference $ bloqueo) en java.lang.object.wait (objeto.Java:485) AT java.lang.ref.reference $ referenceHandler.run (reference.java:116) - bloqueado <0x27d5e650> (a java.lang.ref.reference $ bloqueo) "main" prio = 6 tid = 0x008a6c00 nid = 0x22ec en object.wait () [0x0098f000] j -java.lang.lang.lang.lang.lang. Timed_waiting (en el monitor de objeto) en java.lang.object.wait (método nativo) - esperando <0x22c303c8> (a org.eclipse.core.runtime.internal.adaptor.semaphore) en org.eclipse.core.runtime.internal.adaptor.semaphore.acileire (semaphore (semaphore) locked <0x22c303c8> (a org.eclipse.core.runtime.internal.adaptor.Semaphore) at org.eclipse.core.runtime.adaptor.EclipseStarter.updateSplash(EclipseStarter.java:1251) at org.eclipse.core.runtime.adaptor.eclipseStarter.setStartlevel (eclipseStarter.java:1213) en org.eclipse.core.runtime.adaptor.eclipseStarter.startup (eclipsestarter.Java:288) AT en AT org.eclipse.core.runtime.adaptor.eclipSeSeSeTarter.run (eclipseSeStarter.java:175) en Sun.reflect.nativemethodaccessorImpl.invoke0 (método nativo) en Sun.reflect.nativemethodaccessiMpl.invoke (nativemethodacCessesMpl.Java:39) Sun.Reflect.DelegatingMethodacCessorImpl.invoke (delegandomethodaccessorImpl.java:25) en java.lang.reflect.method.invoke (métod.java:597) en org.eclipse.equinox.launcher.main.invokeframework (main.java:622222222222222222222222222222222222222s. org.eclipse.equinox.launcher.main.basicrun (main.java:577) en org.eclipse.equinox.launcher.main.run (main.java:1410) en org.eclipse.equinox.launcher.main.main (main.java:1386) " tid = 0x02bba000 nid = 0xdb4 runnable "VM Task Task Hilo" prio = 10 tid = 0x02c0e400 nid = 0x24ac esperando en condiciónjni referencias globales: 677
analizar:
Según el aviso, ambos subprocesos usan el objeto FTPClient como bloqueo, y el anterior que obtiene la cerradura tiene que esperar a que el siguiente necesite el resultado de retorno de la cerradura, causando un punto muerto. Estos dos lugares son:
(1) en org.apache.commons.net.telnet.telnetinputstream .__ Read (TelnetInputstrS
eam.java:122)
(2) - Bloqueado <0x22942280> (a org.apache.commons.net.ftp.ftpclient)
en com.sagemcom.dc.ftp.client.ftpclientfactoryimpl.getclient (ftpclientfa
ctoryimpl.java:35)
- bloqueado <0x228f9310> (un java.lang.object)
El primero es el bloqueo utilizado por el sistema en sí, y el segundo se agrega en mi código. Se resolverá cambiando un objeto en su propio código para bloquearlo.
Resumir
Jstack es bastante útil para resolver problemas. La información es concisa y efectiva. De hecho, hay muchas herramientas de análisis gráficas basadas en ella. Sin embargo, Jstack debe ser compatible con JDK1.6 o superior.
Lo anterior es todo el contenido de este artículo sobre cómo resolver problemas de punto muerto a través del análisis JSTACK. Espero que sea útil para todos. Los amigos interesados pueden continuar referiéndose a otros temas relacionados en este sitio. Si hay alguna deficiencia, deje un mensaje para señalarlo. ¡Gracias amigos por su apoyo para este sitio!