java命令--jstack⼯具查看JVM堆栈信息
介绍
jstack是java虚拟机⾃带的⼀种堆栈跟踪⼯具。jstack⽤于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-
d64"，Windows的jstack使⽤⽅式只⽀持以下的这种⽅式：
jstack [-l] pid
主要分为两个功能：
a．针对活着的进程做本地的或远程的线程dump；
b．针对core⽂件做线程dump。
jstack⽤于⽣成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每⼀条线程正在执⾏的⽅法堆栈的集合，⽣成线程快照的主要⽬的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。线程出现停顿的时候通过jstack来查看各个线程的调⽤堆栈，就可以知道
没有响应的线程到底在后台做什么事情，或者等待什么资源。如果java程序崩溃⽣成core⽂件，jstack⼯具可以⽤来获得core⽂件的java stack和native stack的信息，从⽽可以轻松地知道java程序是如何崩溃和在程序何处发⽣问题。另外，jstack⼯具还可以附属到正在运⾏的java程序中，看到当时运⾏的java程序的java stack和native stack的信息, 如果现在运⾏的java程序呈现hung的状态，jstack是⾮常有⽤的。
So,jstack命令主要⽤来查看Java线程的调⽤堆栈的，可以⽤来分析线程问题（如死锁）。
# 线程状态
想要通过jstack命令来分析线程的情况的话，⾸先要知道线程都有哪些状态，下⾯这些状态是我们使⽤jstack命令查看线程堆栈信息时可能会看到的线程的⼏种状态：
NEW，未启动的。不会出现在Dump中。
RUNNABLE，在虚拟机内执⾏的。运⾏中状态，可能⾥⾯还能看到locked字样，表明它获得了某把锁。
BLOCKED，受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。
WATING,⽆限期等待另⼀个线程执⾏特定操作。等待某个condition或monitor发⽣，⼀般停留在park(), wait(), sleep(),join() 等语句⾥。
TIMED_WATING，有时限的等待另⼀个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。
TERMINATED，已退出的。
# Monitor
在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。 Monitor是 Java中⽤以实现线程之间的互斥与协作的主要⼿段，它可以看成是对象或者 Class的锁。每⼀个对象都有，也仅有⼀个 monitor。下⾯这个图，描述了线程和 Monitor之间关系，以及线程的状态转换图：
进⼊区(Entrt Set)：表⽰线程通过synchronized要求获取对象的锁。如果对象未被锁住，则迚⼊拥有者；否则则在进⼊区等待。⼀旦对象锁被其他线程释放,⽴即参与竞争。
拥有者(The Owner)：表⽰某⼀线程成功竞争到对象锁。
等待区(Wait Set)：表⽰线程通过对象的wait⽅法，释放对象的锁，并在等待区等待被唤醒。
从图中可以看出，⼀个 Monitor在某个时刻，只能被⼀个线程拥有，该线程就是 “Active Thread”，⽽其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”⾥⾯等候。在 “Entry Set”中等
待的线程状态是 “Waiting for monitor entry”，⽽在“Wait Set”中等待的线程状态是 “in Object.wait()”。先看 “Entry Set”⾥⾯的线程。我们称被 synchronized保护起来的代码段为临界区。当⼀个线程申请进⼊临界区时，它就进⼊了 “Entry Set”队列。对应的 code就像：
synchronized(obj) {
.........
}
# 调⽤修饰
表⽰线程在⽅法调⽤时，额外的重要的操作。线程Dump分析的重要信息。修饰上⽅的⽅法调⽤。
locked <；地址> ⽬标：使⽤synchronized申请对象锁成功，监视器的拥有者。
waiting to lock <；地址> ⽬标：使⽤synchronized申请对象锁未成功，在迚⼊区等待。
waiting on <；地址> ⽬标：使⽤synchronized申请对象锁成功后，释放锁幵在等待区等待。
parking to wait for <；地址> ⽬标
locked
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement
- locked <0x00002aab63bf7f58> (a oracle.jdbc.driver.T4CConnection)
at com.internal.db.datasource.PooledConnection.prepareStatement
通过synchronized关键字，成功获取到了对象的锁，成为监视器的拥有者，在临界区内操作。对象锁是可以线程重⼊的。
waiting to lock
at com.impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
- waiting to lock <0x0000000097ba9aa8> (a CacheHolder)
at com.impl.CacheGroup$Index.findHolder
at com.impl.ContextImpl.find
at com.jiuqi.dna.bap.basedatamon.util.BaseDataCenter.findInfo
通过synchronized关键字，没有获取到了对象的锁，线程在监视器的进⼊区等待。在调⽤栈顶出现，线程状态为Blocked。
waiting on
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000da2defb0> (a WorkingThread)
at com.WorkToDo
- locked <0x00000000da2defb0> (a WorkingThread)
at com.impl.WorkingThread.run
通过synchronized关键字，成功获取到了对象的锁后，调⽤了wait⽅法，进⼊对象的等待区等待。在调⽤栈顶出现，线程状态为WAITING或TIMED_WATING。
parking to wait for
park是基本的线程阻塞原语，不通过监视器在对象上阻塞。随concurrent包会出现的新的机制，不synchronized体系不同。
# 线程动作
线程状态产⽣的原因
runnable：状态⼀般为RUNNABLE。
in Object.wait()：等待区等待，状态为WAITING或TIMED_WAITING。
waiting for monitor entry：进⼊区等待，状态为BLOCKED。
waiting on condition：等待区等待、被park。
sleeping：休眠的线程，调⽤了Thread.sleep()。
Wait on condition 该状态出现在线程等待某个条件的发⽣。具体是什么原因，可以结合 stacktrace来分析。最常见的情况就是线程处于sleep状态，等待被唤醒。常见的情况还有等待⽹络IO：在java引⼊nio
之前，对于每个⽹络连接，都有⼀个对应的线程来处理⽹络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，⽽且给操作系统的线程调度也带来压⼒。在 NewIO⾥采⽤了新的机制，编写的服务器程序的性能和可扩展性都得到提⾼。正等待⽹络读写，这可能是⼀个⽹络瓶颈的征兆。因为⽹络阻塞导致线程⽆法执⾏。⼀种情况是⽹络⾮常忙，⼏乎消耗了所有的带宽，仍然有⼤量数据等待⽹络读写；另⼀种情况也可能是⽹络空闲，但由于路由等问题，导致包⽆法正常的到达。所以要结合系统的⼀些性能观察⼯具来综合分析，⽐如 netstat统计单位时间的发送包的数⽬，如果很明显超过了所在⽹络带宽的限制 ; 观察 cpu的利⽤率，如果系统态的 CPU时间，相对于⽤户态的 CPU时间⽐例较⾼；如果程序运⾏在 Solaris 10平台上，可以⽤ dtrace⼯具看系统调⽤的情况，如果观察到 read/write的系统调⽤的次数或者运⾏时间遥遥领先；这些都指向由于⽹络带宽所限导致的⽹络瓶颈。（来⾃）
命令格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP
常⽤参数说明
1）options：
executable Java executable from which the core dump was produced.(可能是产⽣core dump的java可执⾏程序)
core 将被打印信息的core dump⽂件
remote-hostname-or-IP 远程debug服务的主机名或ip
server-id 唯⼀id，假如⼀台主机上多个远程debug服务
2）基本参数：
-F当’jstack [-l] pid’没有相应的时候强制打印栈信息，如果直接jstack⽆响应时，⽤于强制jstack），⼀般情况不需要使⽤
-l长列表. 打印关于锁的附加信息，例如属于urrent的ownable synchronizers列表，会使得JVM停顿得长久得多（可能会差很多倍，⽐如普通的jstack可能⼏毫秒和⼀次GC 没区别，加了-l 就是近⼀秒的时间），-l 建议不要⽤。⼀般情况不需要使⽤
-
m打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈，显⽰上Native的栈帧，⼀般应⽤排查不需要使⽤
-h | -help打印帮助信息
pid 需要被打印配置信息的java进程id，可以⽤jps查询.
线程dump的分析⼯具：
⼀个⼩巧的Jar包，能⽅便的按状态，线程名称，线程停留的函数排序，快速浏览。
Spotify提供的Web版在线分析⼯具，可以将锁或条件相关联的线程聚合到⼀起。
使⽤实例
1、jstack pid
~$ jps -ml
org.apache.catalina.startup.Bootstrap
~$ jstack 5661
2013-04-16 21:09:27
Full thread dump Java HotSpot(TM) Server VM (20.10-b01 mixed mode):
"Attach Listener" daemon prio=10 tid=0x70e95400 nid=0x2265 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"http-bio-8080-exec-20" daemon prio=10 tid=0x08a35800 nid=0x1d42 waiting on condition [0x70997000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x766a27b8> (a urrent.locks.AbstractQueuedSynchronizer$ConditionObject)
java64位at urrent.locks.LockSupport.park(LockSupport.java:156)
at urrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSyn
chronizer.java:1987) at urrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at at.util.threads.TaskQueue.take(TaskQueue.java:104)
at at.util.threads.TaskQueue.take(TaskQueue.java:32)
at Task(ThreadPoolExecutor.java:947)
at urrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
........
#jstack -l 4089 &，查看1.txt内容如下所⽰：
2014-03-14 10:47:04
Full thread dump Java HotSpot(TM) Client VM (20.45-b01 mixed mode, sharing):
"Attach Listener" daemon prio=10 tid=0x08251400 nid=0x11bd runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"DestroyJavaVM" prio=10 tid=0xb3a0a800 nid=0xffa waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Query Listener" prio=10 tid=0xb3a09800 nid=0x1023 runnable [0xb3b72000]
java.lang.Thread.State: RUNNABLE
at java.PlainSocketImpl.socketAccept(Native Method)
at java.PlainSocketImpl.accept(PlainSocketImpl.java:408)
-
locked <0x70a84430> (a java.SocksSocketImpl)
at java.ServerSocket.implAccept(ServerSocket.java:462)
at java.ServerSocket.accept(ServerSocket.java:430)
at ls.hat.internal.server.QueryListener.waitForRequests(QueryListener.java:76)
at ls.hat.internal.server.QueryListener.run(QueryListener.java:65)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- None
"Low Memory Detector" daemon prio=10 tid=0x08220400 nid=0x1000 runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
-
None
"C1 CompilerThread0" daemon prio=10 tid=0x08214c00 nid=0xfff waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Signal Dispatcher" daemon prio=10 tid=0x08213000 nid=0xffe runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Finalizer" daemon prio=10 tid=0x0820bc00 nid=0xffd in Object.wait() [0xb5075000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x7a2b6f50> (a f.ReferenceQueue$Lock)
at ve(ReferenceQueue.java:118)
- locked <0x7a2b6f50> (a f.ReferenceQueue$Lock)
at ve(ReferenceQueue.java:134)
at f.Finalizer$FinalizerThread.run(Finalizer.java:171)
Locked ownable synchronizers:
- None
"Reference Handler" daemon prio=10 tid=0x0820a400 nid=0xffc in Object.wait() [0xb50c7000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
-
waiting on <0x7a2b6fe0> (a f.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at f.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x7a2b6fe0> (a f.Reference$Lock)
Locked ownable synchronizers:
- None
"VM Thread" prio=10 tid=0x08200000 nid=0xffb runnable
"VM Periodic Task Thread" prio=10 tid=0x08222400 nid=0x1001 waiting on condition
JNI global references: 1317
⼀般情况下，通过jstack输出的线程信息主要包括：jvm⾃⾝线程、⽤户线程等。其中jvm线程会在jvm启动时就会存在。对于⽤户线程则是在⽤户访问时才会⽣成。
2、jstack 查看线程具体在做什么，可看出哪些线程在长时间占⽤CPU，尽快定位问题和解决问题
www.iteye/topic/1114219
21125 co_ad2 18 0 1817m 776m 9712 S 3.3 4.9 12:03.24 java
5284 co_ad 21 0 3028m 2.5g 9432 S 1.0 16.3 6629:44 ja
这⾥我们分析21125这个java进程
先输⼊top，然后再按shift+h 或“H”，此时打开的是线程视图，pid为线程号
21233 co_ad2 15 0 1807m 630m 9492 S 1.3 4.0 0:05.12 java
20503 co_ad2_s 15 0 1360m 560m 9176 S 0.3 3.6 0:46.72 java
这⾥我们分析21233这个线程，并且注意的是，这个线程是属于21125这个进程的。
3.使⽤jstack命令输出这⼀时刻的线程栈，保存到⽂件，命名为jstack.log。注意：输出线程栈和保存top命令快照尽量同时进⾏。
由于jstack.log⽂件记录的线程ID是16进制，需要将top命令展⽰的线程号转换为16进制。
4. jstack查这个线程的信息
jstack [进程]|grep -A 10 [线程的16进制]
即： jstack 21125|grep -A 10 52f1
-A 10表⽰查到所在⾏的后10⾏。21233⽤计算器转换为16进制52f1，注意字母是⼩写。
结果：
"http-8081-11" daemon prio=10 tid=0x00002aab049a1800 nid=0x52bb in Object.wait() [0x0000000042c75000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at at.util.JIoEndpoint$Worker.await(JIoEndpoint.java:416)
在结果中查52f1，可看到当前线程在做什么。
3、代码⽰例
运⾏代码：
/**
* @author hollis
*/
public class JStackDemo1 {
public static void main(String[] args) {
while (true) {
//Do Nothing
}
}
}
先是有jps查看进程号：
hollis@hos:~$ jps
29788 JStackDemo1
29834 Jps
lipse.equinox.launcher_1.3.0.v20130327-1440.jar
然后使⽤jstack 查看堆栈信息：
hollis@hos:~$ jstack 29788
2015-04-17 23:47:31
...此处省略若⼲内容...
"main" prio=10 tid=0x00007f197800a000 nid=0x7462 runnable [0x00007f197f7e1000]
java.lang.Thread.State: RUNNABLE
at javaCommand.JStackDemo1.main(JStackDemo1.java:7)
我们可以从这段堆栈信息中看出什么来呢？我们可以看到，当前⼀共有⼀条⽤户级别线程，线程处于runnable状态，执⾏到JStackDemo1.java的第七⾏。看下⾯代码：
/**
* @author hollis
*/
public class JStackDemo1 {
public static void main(String[] args) {
Thread thread = new Thread(new Thread1());
thread.start();
}
}
class Thread1 implements Runnable{
@Override
public void run() {
while(true){
System.out.println(1);
}
}
}
线程堆栈信息如下：
"Reference Handler" daemon prio=10 tid=0x00007fbbcc06e000 nid=0x286c in Object.wait() [0x00007fbbc8dfc000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000783e066e0> (a f.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at f.Reference$ReferenceHandler.run(Reference.java:133)
- locked <0x0000000783e066e0> (a f.Reference$Lock)
我们能看到：
线程的状态： WAITING 线程的调⽤栈线程的当前锁住的资源： <0x0000000783e066e0> 线程当前等待的资源：<0x0000000783e066e0>
为什么同时锁住的等待同⼀个资源：
线程的执⾏中，先获得了这个对象的 Monitor（对应于 locked <0x0000000783e066e0>）。当执⾏到 obj.wait(), 线程即放弃了 Monitor的所有权，进⼊ “wait set”队列（对应于 waiting on <0x0000000783e066e0> ）。
如何分析
1、线程Dump的分析
# 原则
结合代码阅读的推理。需要线程Dump和源码的相互推导和印证。
造成Bug的根源往往丌会在调⽤栈上直接体现,⼀定格外注意线程当前调⽤之前的所有调⽤。
发表评论