Je viens d'utiliser JSTACK pour résoudre le problème d'une impasse du processus - en fait, je l'ai résolu il y a longtemps, et je connais la raison, mais je n'ai pas trouvé l'emplacement de l'impasse, donc je ne suis pas très disposé à le faire.
Le processus est à peu près comme suit:
(0) Exigences environnementales, JDK 1,6 et plus
(1) Trouvez d'abord le PID du processus. Dans Windows, ouvrez le gestionnaire de processus et triez-le par son nom. Vous pouvez trouver un processus appelé javaw.exe (les processus de machine virtuelle Java sont tous appelés javaw.exe). Vous devez trouver quel processus est votre processus, souvenir de la liste de processus actuelle, puis redémarrer votre processus. Celui qui a été rafraîchi par le PID est votre processus.
(2) Exécuter sous CMD: JSTACK PID, JSTACK tapera une série d'informations sur la console
(3) Analyser les informations ci-dessus
Exemple:
Les informations JStack pour ma question sont les suivantes:
C: / documents et paramètres / utilisateur> JSTACK 66522012-06-07 21: 32: 02 Full Dump Java Hotspot (TM) VM Client (16.3-b01 Mode mixte, partage): "Thread-1" Daemon Prio = 6 Tid = 0x03010C00 NID = 0xcdc en attente de moniron [0x0339f000] Java.lang.Hread. Blocké (sur moniteur d'objet) sur org.apache.commons.net.telnet.telnetInputStream .__ Read (telneTinputStream.java:122) - En attente de verrouillage <0x22942280> (a org.apache.commons.net.ftp.ftpclient) à l'org.apache.commons.net.ftp.ftpclient) à la org.apache.commons.net.telnet.telnetinputstream.run (telnetinputStream.java:535) sur java.lang.thread.run (thread.java:619) "Framework Event Dispatcher" Daemon Pio = 6 TID = 0x03010400 NID = 0x998 dans Object.Wait () [0x033400] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x228fa800> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.eventManager $ eventthread.getNExtevent (eventManager.java:400) - Locké <0x228fa800> (a org.eclipse.osgi.framework.eventmgr.eventManager $ Eventthread) at a at org.eclipse.osgi.framework.eventmgr.eventManager $ eventthread.run (eventManager.java:336) "Départeur d'événement de niveau" Daemon Prio = 6 Tid = 0x02fcf400 NID = 0x2638 dans Object.Wait () [0x032De000] Java.Lang.threadaRead: Office Monitor) ATS ATT java.lang.object.wait (méthode native) - en attente <0x2295db48> (a [i) sur java.lang.object.wait (objet.java:485) sur org.apache.commons.net.telnet.telnetInputStream.read (telneTinputStream.java:339) -Lele (A [i) sur org.apache.commons.net.telnet.telnetinputStream.read (telnetInputStream.java:466) sur java.io.bufferedinputstream.read1 (tofferedInputStream.java:256) à java.io.botteredInputStream.read (buffredInputStream. <0x2295fe18> (a java.io.bufferedinputStream) sur Sun.nio.cs.Streamdecoder.readbytes (streamdecoder.java:264) sur sun.nio.cs.streamdecoder.impleread (streamdecoder.java:306) attamdecoder. Sun.nio.cs.Streamdecoder.Read (streamdecoder.java:158) - Locké <0x22961f88> (a java.io.inputstreamreader) sur java.io.inputstreamreader.read (inputStreamReader.Java:167) java.io.botteredreader.fill (bufferedreader.java:136) sur java.io.bopereader.readline (buffereDeader.java:299) - Locké <0x22961f88> (a java.io.inputStreamReader) at) java.io.bottereDeader.readline (buffereDeader.java:362) sur org.apache.commons.net.ftp.ftp .__ getReply (ftp.java:264) à org.apache.commons.net.ftp.ftp._connectaction_ (ftp.java:335) à la org.apache.commons.net.ftp.ftpclient._connectAction_ (ftpclient.java:550) sur org.apache.commons.net.socketclient.connect (socketClient.java:163) at com.mycompany.dc.ftp.client.ftpclientImpl.connect (ftpclientImpl.java:75) - Locked <0x22942280> (a org.apache.commons.net.ftp.ftpclient) at com.mycompany.dc.ftp.client.ftpclientfactoryimpl.getClient (ftpclientfactoryimpl.java:35) - verrouillé <0x228f9310> (a java.lang.object) à ftpclienttest.activator.start (activateur.java:43) sur ftpclientTest.Activator. org.eclipse.osgi.framework.internal.core.bundleContexImpl 1 $. org.eclipse.osgi.framework.internal.core.bundlecontextImpl.startActivator (bundlecontextimpl.java:702) sur org.eclipse.osgi.framework.internal.core.bundlecontex org.eclipse.osgi.framework.internal.core.bundlehost.startworker (bundlehost.java:381) à org.eclipse.osgi.framework.internal.core org.eclipse.osgi.framework.internal.core.framework.resumebundle (framework.java:1131) sur org.eclipse.osgi.framework.internal.core.startlevelmanager.resumebundles (StarkEvelManager.Java:559) ATT org.eclipse.osgi.framework.internal.core.startlevelmanager.resumebundles (starkevelmanager.java:544) sur org.eclipse.osgi.framework.internal.core.startlevelmanager.incfwsl (starkervelmanager.java:457) at à at atterser. org.eclipse.osgi.framework.internal.core.startlevelmanager.dosetStartlevel (StarkEvelManager.java:243) - Locké <0x27e68d70> (a java.lang.object) à l'adresse org.eclipse.osgi.framework.internal.core.startlevelmanager.dispatchEvent (StarkEvelManager.java:438) à org.eclipse.osgi.framework.internal.core.startlevelmanager.dispatchEvent (starketmanager.java:1) à la org.eclipse.osgi.framework.eventmgr.eventmanager.dispatchEvent (eventManager.java:230) sur org.eclipse.osgi.framework.eventmgr.eventManager $ Eventthread.run (eventmanager.java:340) "Framework Active Thread" Prio = 6 TID = 0x02ff1800) nid=0x1fbc in Object.wait() [0x0328f000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x27e65770> (a org.eclipse.osgi.framework.internal.core.Framework) at org.eclipse.osgi.framework.internal.core.framework.run (framework.java:1817) - verrouillé <0x27e65770> (a org.eclipse.osgi.framework.internal.core.framework) à java.thread.run (thread.java:619) à java.thread.run (thread.java:619) "OSGIG. prio = 6 tid = 0x03005400 NID = 0x225c attendant l'état [0x0323f000] java.lang.thread.state: timed_waiting (sleep) sur java.lang.thread.sleep (méthode native) à la même manière org.eclipse.osgi.framework.internal.core.frameworkConsole.runconsole (frameworkconsole.java:125) à org.eclipse.osgi.framework.internal.core.frameworkconsole.run (frameworksonsole.java:104) at à la java.lang.thread.run (thread.java:619) "Détecteur de mémoire basse" Daemon Prio = 6 TOD = 0x02C09800 NID = 0x1d68 Runnable [0x000000000] Java.lang.thread.state: runnable "compilerthread0" Daemon Prio = 10 idd = 0x02c03000 nid = 0x24c) Condition [0x000000000] java.lang.thread.state: Runnable "attacher auditeur" Daemon Prio = 10 Tid = 0x02C01800 NID = 0x1138 Waiting on Statue [0x000000000] Java.lang.thread.state: runnable "Dispatcher" Runnable Prio = 10 Tid = 0x02C20C00 Nid = 0x18ac Runnable = 10 Tid = 0x02C20C00 Nid = 0x18ac Runnable = 10 Tid = 0x02c2 [0x000000000] java.lang.thread.state: runnable "finalizer" daemon prio = 8 tid = 0x02bc0400 nid = 0x11ac dans object.wait () [0x02d8f000] java.lang.thread.state: waying (sur objet) à java.lang.object.wait (méthode native) - Waye <0x27d5e5c8> (a java.lang.ref.referenceeue $ Lock) sur java.lang.ref.referencequeue.remove (Referenceeue.java:118) - Locked <0x27d5e5c8> (a java.lang.ref.referenceeue $ Lock) at at a at java.lang.ref.referenceeue.remove (ReferenceQueue.java:134) sur java.lang.ref.finalizer $ finalizerthread.run (finalizer.java:159) "Handler de référence" prio = 10 tid = 0x02bb800 nid = 0x9cc dans object.wait () [0x02d3f java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x27d5e650> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.reference $ ReferenceHandler.Run (Reference.java:116) - Locké <0x27d5e650> (a java.lang.ref.reference $ Lock) "Main" prio = 6 tid = 0x008a6c00 nid = 0x22ec dans object.wait () [0x0098f000] Java.Lang.thread.State: [0x0098f000] Java.Lang.thread.State: [0x0098f000] Java.Lang.thread.State: [0x0098f000] TIMED_WAITING (sur le moniteur d'objet) sur java.lang.object.wait (méthode native) - En attendant <0x22c303c8> (a org.eclipse.core.runtime.internal.adaptor.semaphore) à org.eclipse.core.runtime.internal.adaptor.semaphore.acquire (Semiaphore:55) -Semaphore.acquire (Semiaphore:55) -Semaphore.acquire (Semiaphore:55) -Semaphore.Acquire (SemitHore:55) -Semaphore.Acquire (Semiaphore: Verrouillé <0x22c303c8> (a org.eclipse.core.runtime.internal.adaptor.semaphore) à org.eclipse.core.runtime.adaptor.eclipsestarter.updatesplash (eclipsestarter.java:1251) à la org.eclipse.core.runtime.adaptor.eclipsestarter.setstartlevel (eclipsestarter.java:1213) à org.eclipse.core.runtime.adaptor.eclipsestarter.startup (eclipsestarter.java:288) at org.eclipse.core.runtime.adaptor.eclipsestarter.run (eclipsestarter.java:175) à sun.reflect.nativemethodaccessorimpreshy Sun.Reflect.delegatingMethodAccessOrimpl.invoke (délégation deMethodaccessorimp.java:25) à java.lang.reflect.method.invoke (méthode.java:597) à org.eclipse.equinox.launcher org.eclipse.equinox.launcher.main.basicrun (main.java:577) sur org.eclipse.equinox.launcher.main.run (main.java:1410) à org.eclipse.equinox.launcher.main.main (main.java:1386) " Tid = 0x02bba000 NID = 0xdb4 Runnable "Vm Tâche périodique Thread" PRIO = 10 TID = 0x02C0E400 NID = 0x24AC attend sur conditionjni références globales: 677
analyser:
Selon l'invite, les deux threads utilisent l'objet FTPClient comme verrouillage, et le précédent qui obtient le verrou doit attendre que le suivant ait besoin du résultat de retour du verrou, provoquant une impasse. Ces deux endroits sont:
(1) sur org.apache.commons.net.telnet.telnetInputStream .__ Read (TelnetinputSt
eam.java:122)
(2) - Verrouillé <0x22942280> (a org.apache.commons.net.ftp.ftpclient)
sur com.sagemcom.dc.ftp.client.ftpclientfactoryimpl.getClient (ftpclientfa
ctoryimpl.java:35)
- Verrouillé <0x228f9310> (a java.lang.object)
Le premier est le verrou utilisé par le système lui-même, et le second est ajouté dans mon code. Il sera résolu en modifiant un objet dans votre propre code pour le verrouiller.
Résumer
JSTACK est très utile pour résoudre les problèmes. Les informations sont concises et efficaces. En fait, il existe de nombreux outils d'analyse graphique basés sur celui-ci. Cependant, JStack doit être pris en charge par JDK1.6 ou supérieur.
Ce qui précède est l'intégralité du contenu de cet article sur la résolution des problèmes de blocage du processus grâce à l'analyse JSTACK. J'espère que ce sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à d'autres sujets connexes sur ce site. S'il y a des lacunes, veuillez laisser un message pour le signaler. Merci vos amis pour votre soutien pour ce site!