jstack命令 详解 - CSDN博客
jstack命令 详解
java进程ID或core&file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项&-J-d64&，Windows的jstack使用方式只支持以下的这种方式：
如core文件，jstack工具可以用来获得core文件的java&stack和native&stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java&stack和native&stack的信息,&如果现在运行的java程序呈现hung的状态，jstack是非常有用的。
2、命令格式
3、常用参数说明
core&dump的java可执行程序)
core&dump文件
debug服务的主机名或ip
id,假如一台主机上多个远程debug服务&
2）、基本参数：
’jstack&[-l]&pid’没有相应的时候强制打印栈信息
.&打印关于锁的附加信息,例如属于java.util.concurrent的ownable&synchronizers列表.
java和native&c/c++框架的所有栈信息.
java进程id,可以用jps查询.
4、jstack分析线程死锁
线程死锁的代码如下。
public&class&ThreadDeadLockDemo {&&
&&&&public&static&void&main(String[]&args)&{&&
&&&&&&&&final&Object&obj_1&=&new&Object(),&obj_2&=&new&Object();&&
&&&&&&&&&&
&&&&&&&&Thread first =&new&Thread(&first&){&&
&&&&&&&&&&&&@Override&&
&&&&&&&&&&&&public&void&run()&{&&
&&&&&&&&&&&&&&&&synchronized&(obj_1)&{&&
&&&&&&&&&&&&&&&&&&&&try&{&&
&&&&&&&&&&&&&&&&&&&&&&&&Thread.sleep(3000);&&
&&&&&&&&&&&&&&&&&&&&}&catch&(InterruptedException&e)&{}&&
&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&synchronized&(obj_2)&{&&
&&&&&&&&&&&&&&&&&&&&&&&&System.out.println(&first thread done.&);&&
&&&&&&&&&&&&&&&&&&&&}&&
&&&&&&&&&&&&&&&&}&&
&&&&&&&&&&&&}&&
&&&&&&&&};&&
&&&&&&&&&&
&&&&&&&&Thread second =&new&Thread(&second&){&&
&&&&&&&&&&&&@Override&&
&&&&&&&&&&&&public&void&run()&{&&
&&&&&&&&&&&&&&&&synchronized&(obj_2)&{&&
&&&&&&&&&&&&&&&&&&&&try&{&&
&&&&&&&&&&&&&&&&&&&&&&&&Thread.sleep(3000);&&
&&&&&&&&&&&&&&&&&&&&}&catch&(InterruptedException&e)&{}&&
&&&&&&&&&&&&&&&&&&&&&&
&&&&&&&&&&&&&&&&&&&&synchronized&(obj_1)&{&&
&&&&&&&&&&&&&&&&&&&&&&&&System.out.println(&seconde thread done.&);&&
&&&&&&&&&&&&&&&&&&&&}&&
&&&&&&&&&&&&&&&&}&&
&&&&&&&&&&&&}&&
&&&&&&&&};&&
&&&&&&&&&&
& & & & first.start();&&
& & & & second.start();&&
执行程序，会引起线程死锁。
调用 jstack命令，查看当前进程的线程状态，打印信息如下。可以发现进程已经发生了死锁，first线程等待second线程释放资源，同时，second线程也在等待first线程释放资源。
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed mode):
&Attach Listener& daemon prio=10 tid=0x1000 nid=0x7c1 waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&DestroyJavaVM& prio=10 tid=0x5800 nid=0x793 waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&second& prio=10 tid=0xaa800 nid=0x7a1 waiting for monitor entry [0xc1000]
& &java.lang.Thread.State: BLOCKED (on object monitor)
& & & & at ThreadDeadLockDemo$2.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b40& (a java.lang.Object)
& & & & - locked &0x6b50& (a java.lang.Object)
&first& prio=10 tid=0xa8800 nid=0x7a0 waiting for monitor entry [0xc2000]
& &java.lang.Thread.State: BLOCKED (on object monitor)
& & & & at ThreadDeadLockDemo$1.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b50& (a java.lang.Object)
& & & & - locked &0x6b40& (a java.lang.Object)
&Low Memory Detector& daemon prio=10 tid=0xf800 nid=0x79e runnable [0x0000]
& &java.lang.Thread.State: RUNNABLE
&C2 CompilerThread1& daemon prio=10 tid=0xd800 nid=0x79d waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&C2 CompilerThread0& daemon prio=10 tid=0xa800 nid=0x79c waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&Signal Dispatcher& daemon prio=10 tid=0x8800 nid=0x79b runnable [0x0000]
& &java.lang.Thread.State: RUNNABLE
&Finalizer& daemon prio=10 tid=0xc000 nid=0x79a in Object.wait() [0x00007f87facc8000]
& &java.lang.Thread.State: WAITING (on object monitor)
& & & & at java.lang.Object.wait(Native Method)
& & & & - waiting on &0x1300& (a java.lang.ref.ReferenceQueue$Lock)
& & & & at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
& & & & - locked &0x1300& (a java.lang.ref.ReferenceQueue$Lock)
& & & & at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
& & & & at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171)
&Reference Handler& daemon prio=10 tid=0xa000 nid=0x799 in Object.wait() [0x00007f87fadc9000]
& &java.lang.Thread.State: WAITING (on object monitor)
& & & & at java.lang.Object.wait(Native Method)
& & & & - waiting on &0x11d8& (a java.lang.ref.Reference$Lock)
& & & & at java.lang.Object.wait(Object.java:485)
& & & & at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
& & & & - locked &0x11d8& (a java.lang.ref.Reference$Lock)
&VM Thread& prio=10 tid=0x3800 nid=0x798 runnable&
&GC task thread#0 (ParallelGC)& prio=10 tid=0x9000 nid=0x794 runnable&
&GC task thread#1 (ParallelGC)& prio=10 tid=0xa800 nid=0x795 runnable&
&GC task thread#2 (ParallelGC)& prio=10 tid=0xc800 nid=0x796 runnable&
&GC task thread#3 (ParallelGC)& prio=10 tid=0xe800 nid=0x797 runnable&
&VM Periodic Task Thread& prio=10 tid=0xa800 nid=0x79f waiting on condition&
JNI global references: 882
Found one Java-level deadlock:
=============================
& waiting to lock monitor 0x5f10 (object 0x6b40, a java.lang.Object),
& which is held by &first&
& waiting to lock monitor 0x4b60 (object 0x6b50, a java.lang.Object),
& which is held by &second&
Java stack information for the threads listed above:
===================================================
& & & & at ThreadDeadLockDemo$2.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b40& (a java.lang.Object)
& & & & - locked &0x6b50& (a java.lang.Object)
& & & & at ThreadDeadLockDemo$1.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b50& (a java.lang.Object)
& & & & - locked &0x6b40& (a java.lang.Object)
Found 1 deadlock.
&Attach Listener& daemon prio=10 tid=0x1000 nid=0x7c1 waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&DestroyJavaVM& prio=10 tid=0x5800 nid=0x793 waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&second& prio=10 tid=0xaa800 nid=0x7a1 waiting for monitor entry [0xc1000]
& &java.lang.Thread.State: BLOCKED (on object monitor)
& & & & at ThreadDeadLockDemo$2.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b40& (a java.lang.Object)
& & & & - locked &0x6b50& (a java.lang.Object)
&first& prio=10 tid=0xa8800 nid=0x7a0 waiting for monitor entry [0xc2000]
& &java.lang.Thread.State: BLOCKED (on object monitor)
& & & & at ThreadDeadLockDemo$1.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b50& (a java.lang.Object)
& & & & - locked &0x6b40& (a java.lang.Object)
&Low Memory Detector& daemon prio=10 tid=0xf800 nid=0x79e runnable [0x0000]
& &java.lang.Thread.State: RUNNABLE
&C2 CompilerThread1& daemon prio=10 tid=0xd800 nid=0x79d waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&C2 CompilerThread0& daemon prio=10 tid=0xa800 nid=0x79c waiting on condition [0x0000]
& &java.lang.Thread.State: RUNNABLE
&Signal Dispatcher& daemon prio=10 tid=0x8800 nid=0x79b runnable [0x0000]
& &java.lang.Thread.State: RUNNABLE
&Finalizer& daemon prio=10 tid=0xc000 nid=0x79a in Object.wait() [0x00007f87facc8000]
& &java.lang.Thread.State: WAITING (on object monitor)
& & & & at java.lang.Object.wait(Native Method)
& & & & - waiting on &0x1300& (a java.lang.ref.ReferenceQueue$Lock)
& & & & at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
& & & & - locked &0x1300& (a java.lang.ref.ReferenceQueue$Lock)
& & & & at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
& & & & at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:171)
&Reference Handler& daemon prio=10 tid=0xa000 nid=0x799 in Object.wait() [0x00007f87fadc9000]
& &java.lang.Thread.State: WAITING (on object monitor)
& & & & at java.lang.Object.wait(Native Method)
& & & & - waiting on &0x11d8& (a java.lang.ref.Reference$Lock)
& & & & at java.lang.Object.wait(Object.java:485)
& & & & at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
& & & & - locked &0x11d8& (a java.lang.ref.Reference$Lock)
&VM Thread& prio=10 tid=0x3800 nid=0x798 runnable&
&GC task thread#0 (ParallelGC)& prio=10 tid=0x9000 nid=0x794 runnable&
&GC task thread#1 (ParallelGC)& prio=10 tid=0xa800 nid=0x795 runnable&
&GC task thread#2 (ParallelGC)& prio=10 tid=0xc800 nid=0x796 runnable&
&GC task thread#3 (ParallelGC)& prio=10 tid=0xe800 nid=0x797 runnable&
&VM Periodic Task Thread& prio=10 tid=0xa800 nid=0x79f waiting on condition&
JNI global references: 882
Found one Java-level deadlock:
=============================
& waiting to lock monitor 0x5f10 (object 0x6b40, a java.lang.Object),
& which is held by &first&
& waiting to lock monitor 0x4b60 (object 0x6b50, a java.lang.Object),
& which is held by &second&
Java stack information for the threads listed above:
===================================================
& & & & at ThreadDeadLockDemo$2.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b40& (a java.lang.Object)
& & & & - locked &0x6b50& (a java.lang.Object)
& & & & at ThreadDeadLockDemo$1.run(ThreadDeadLockDemo.java:10)
& & & & - waiting to lock &0x6b50& (a java.lang.Object)
& & & & - locked &0x6b40& (a java.lang.Object)
Found 1 deadlock.
本文已收录于以下专栏：
相关文章推荐
Attaching to process ID 11827, please wait...
Debugger attached successfully.
Server compiler detect...
生产运行的系统运行时间长了,容易出现运行缓慢,内容不足等问题。 
        如果单靠通过查看代码是很难去发现这些问题,在这一次故障排查中,我也学到了怎样更好的使用jvm监控工具来进行诊断,主要用...
概述jstack可用于导出java运用程序的线程堆栈，其基本使用语法为：
jstack [-l] pid
-l 选项用于打印锁的额外信息。使用示例下面这段代码运行之后会出现死锁现象(因为线程1持有...
Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于java的bin目录下，主要利用JVM内建的指令...
一、前言在二十三天中我们介绍了使用maven来下载工程的依赖库文件，用ant来进行war包的建立。今天我们在这个基础上将使用junit+dbunit来进行带有单元测试报告的框架的架构。目标：每次打包之...
在排查服务器上的java项目出现高cpu使用的情况下从而各种百度的结果，做一个记录。
一般情况下，是因为系统出现瓶颈了，才会去进行调优，而调优则要先找出项目代码中的问题，这次针对ja...
一. 基本命令
X window与文本模式的切换。
通常我们也称文本模式为终端机接口, terminal 或 console喔！Linux默认的情况下会提供六个Terminal来让使用...
jstack命令
该命令打印java线程的堆栈跟踪，可以得知哪些线程被阻塞或正等待，以便于查找如线程死锁的原因用法：
jstack [ option ] pid
-m 打印混合模式(java,c/c...
他的最新文章
讲师：宋宝华
讲师：何宇健
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)对于线上线下服务，针对服务状态，qps，cost等一般都会有一定的监控措施。如果遇到问题，比如cpu占用率高或者程序特别吃内存，对于java程序来说，会用到一些java监控命令和错误定位命令，能够更好的监控服务运行状态，也能够快速定位问题。整理一下我一般使用的命令，下面的命令都是基于oracle hotspot jvm。
概述Monitoring Tools
jps: JVM Process Status Tool, 列出指定机器的jvm pid。
jstat: JVM Statistics Monitoring Tool, jvm的统计监控工具。
jstatd: JVM jstat Daemon, 没用过。
Troubleshooting Tools
jinfo: Configuration Info for Java, 打印java配置信息。
jhat: Heap Dump Browser, 根据dump文件进行分析，可以在浏览器中查看。
jmap: Memory Map for Java, 内存使用情况。
jsadebugd: Serviceability Agent Debug Daemon for Java, 没用过。
jstack: Stack Trace for Java, 打印指定线程的栈信息。
Java Troubleshooting, Profiling, Monitoring and Management Tools
jcmd: JVM Diagnostic Commands Tool, 给jvm发送诊断请求。
jconsole: A JMX-compliant graphical tool for monitoring a Java virtual machine, jvm性能分析，图形界面。
jmc: Java Mission Control, 没用过。
jvisualvm: Java VisualVM, 查看程序的详细信息，图形界面。
还有更多的一些工具，具体可以看下面只整理了自己平时用到的，没有用过的暂时不提，等用过之后再补充。
Monitoring Toolsjpsjps [ options ] [ hostid ]一般只是为了打印出程序的pid, 可能会用到 -m, -l, -v选项, -m列出main方法的参数, -l列出完整jar包, -v列出jvm的参数。
123456789101112~ jps -m27364 Resin --root-directory /usr/local/resin -conf /usr/local/resin/conf/resin.xml -server web -socketwait 33740 -server web -root-directory /usr/local/resin -log-directory /usr/local/resin/log restart21126 Jps -m22478 WatchdogManager -Xloggc:log/gc.log. -server web -root-directory /usr/local/resin -conf /usr/local/resin/conf/resin.xml -log-directory /usr/local/resin/log start --log-directory /usr/local/resin/log~ jps -l27364 com.caucho.server.resin.Resin21147 sun.tools.jps.Jps22478 com.caucho.boot.WatchdogManager~ jps -v
jstatjstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]先看一下有哪些统计项可选
Statistics on the behavior of the class loader.
Statistics of the behavior of the HotSpot Just-in-Time compiler.
Statistics of the behavior of the garbage collected heap.
gccapacity
Statistics of the capacities of the generations and their corresponding spaces.
Summary of garbage collection statistics (same as -gcutil), with the cause of the last and current (if applicable) garbage collection events.
Statistics of the behavior of the new generation.
gcnewcapacity
Statistics of the sizes of the new generations and its corresponding spaces.
Statistics of the behavior of the old and permanent generations.
gcoldcapacity
Statistics of the sizes of the old generation.
gcpermcapacity
Statistics of the sizes of the permanent generation.
Summary of garbage collection statistics.
printcompilation
HotSpot compilation method statistics.
最常用到是gcutil, jstat -gcutil ${pid} , 每1000ms打印一次gc统计情况，一共打&#x次。
12345678910~ jstat -gcutil
313.71517.56
313.71517.56
313.71517.56
313.71517.56
313.71517.56
313.71517.56
313.715......
先看一下打印出来的都是什么：
Description
Survivor space 0 的利用率
Survivor space 1 的利用率
Eden space 的利用率
Old space 的利用率
Permanent space 的利用率
young gc数量
young gc时间
Full gc数量
Full gc时间
所有的gc时间, (YGCT + FGCT)
对java开发工程师来说，这些应该都不陌生。如果在上线过程中，我一般会比较关注YGC和FGC, 如果发现gc过于频繁，会去查看内存的使用情况。jvm内存管理可以看一下，不过是基于jdk1.6的，对于java8，可以看一下。
Troubleshooting Toolsjinfo [ option ] pid除了可以根据pid之外，还可以根据core-file或远程地址。可以查看jvm的配置信息，类似于java程序中System.getProperties()，一般会在查看encoding的时候使用。
1234567891011121314~ jinfo 29209Attaching to process ID 29209, please wait...Debugger attached successfully.Server compiler detected.JVM version is 25.45-b02Java System Properties:java.runtime.name = Java(TM) SE Runtime Environmentjava.vm.version = 25.45-b02sun.boot.library.path = /usr/lib/jvm/java-1.8.0-oracle-1.8.0.45.x86_64/jre/lib/amd64javax.management.builder.initial = com.caucho.jmx.MBeanServerBuilderImpljava.vendor.url = /java.vm.vendor = Oracle Corporation......
jmapjmap [ option ] pid除了可以根据pid之外，还可以根据core-file或远程地址。
jmap -heap ${pid}，可以列出堆的配置和使用情况，如果gc频率过高或内存占用太高，能够从这些信息中找到是哪一块出了问题。
jmap -histo[:live] ${pid}，可以查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象。
1234567891011121314151617181920212223~ jmap -histo:live 29209 | more num
----------------------------------------------1:
java.util.LinkedList$Node4:
[Ljava.lang.O5:
java.lang.String7:
[Lorg.apache.xpath.objects.XO8:
org.apache.xpath.axes.AxesWalker9:
com.caucho.env.actor.ValueActorQueue$ValueItem10:
java.util.HashMap$Node11:
java.util.LinkedList15:
org.apache.xpath.axes.WalkingIterator16:
org.apache.xalan.templates.ElemLiteralResult17:
org.apache.xalan.templates.ElemTextLiteral18:
com.caucho.server.dispatch.Invocation19:
[Ljava.util.HashMap$Node;20:
org.apache.xalan.templates.ElemValueOf21:
java.util.ArrayList......
jmap -dump:format=b,file=dumpFileName ${pid}，jmap还可以把进程的内存使用情况dump到文件中，然后用jhat或jvisualvm分析。对于线上环境不要轻易使用！jmap -dump:live每次都会触发一次Full GC
jhatjhat [ options ] &heap-dump-file&jmap dump出来的文件一般都会很大，jhat分析时可能需要加上-J-Xmx512m这种参数来指定最大堆内存。
1234~ jmap -dump:live,format=b,file=jmapdump 2106Dumping heap to /tmp/jmapdump ...Heap dump file created~ jhat -port 9998 jmapdump
jhat进行分析，并启动一个server，可以在浏览器中查看。图片中只截取了很小一部分。
jstackjstack [ option ] pid除了可以根据pid之外，还可以根据core-file或远程地址。jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码。如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。
在实际应用中，一般会通过ps, printf, top, jstack来查找出最耗cpu的java线程并定位到某一行代码。下面举个实例：
找到对应进程id, 使用ps -ef | fgrep resin | fgrep -v fgrep，找到resin的pid，或者直接使用jps。
找出resin进程中最耗cpu的线程，可以使用ps -Lfp ${pid}或top -Hp ${pid}或ps -mp ${pid} -o THREAD,tid,time，我一般使用top -Hp ${pid}, top命令中根据某一行排序使用”F”，然后选择对应项前的a-z即可。
可以看到cpu使用时间最高的是31255, 我们要根据这个pid得到其16进制数，也就是nid
12~ printf &%x\n& 312557a17
然后使用jstack打印进程的堆栈信息，再根据nid进行grep。
123456789101112~ jstack 29209 | fgrep -A10 7a17&vr_cache(Recver3)& java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked &0x00c8& (a sun.nio.ch.Util$2)
- locked &0x00b0& (a java.util.Collections$UnmodifiableSet)
- locked &0x9958& (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at common.connectionpool.async.Receiver.run(Receiver.java:379)
可以看到CPU消耗都花在了epollWait上，再深究下去，是自己实现的代码中Receiver类中第379行引起的，我们看一下代码：
1int num = this.selector.select(pool.robinTime);
这一行正是selector进行等待的时候，对应于epoll来说就是epoll_wait函数。定位到问题，可以去找对应方案了。如果对IO多路复用机制的可以看一下相关文章，主要有select, poll, epoll。
java图形化界面监控工具jconsole和jvisualvm都需要图形化界面，都可以连接远程server查看。图形化界面看起来都比较容易，在这不做赘述了。
参考