jstack 命令的使用和堆栈分析
原文：https://www.cnblogs.com/kongzhongqijing/articles/3630264.html
一、介绍
jstack 是 Java 虚拟机自带的一种堆栈跟踪工具。jstack 用于打印出给定的 java 进程 ID 或 core file 或远程调试服务的 Java 堆栈信息。
如果是在 64 位机器上，需要指定选项 "-J-d64"，Windows 的 jstack 使用方式只支持以下的这种方式：
jstack [-l] pid主要分为两个功能：
- 针对活着的进程做本地的或远程的线程 dump
- 针对 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 是非常有用的。
线程状态
下面是使用 jstack 命令查看线程堆栈信息时可能会看到的线程的几种状态：
- NEW，未启动的，不会出现在 Dump 中。
- RUNNABLE，在虚拟机内执行的。运行中状态，可能里面还能看到 locked 字样，表明它获得了某把锁。
- BLOCKED，受阻塞并等待监视器锁。被某个锁 (synchronizers) 给 block 住了。
- WATING，无限期等待另一个线程执行特定操作。等待某个 condition 或 monitor 发生，一般停留在 park( )，wait( )，sleep( )，join( ) 等语句里。
- TIMED_WATING，有时限的等待另一个线程的特定操作。和 WAITING 的区别是 wait( ) 等语句加上了时间限制 wait(timeout)。
- TERMINATED，已退出的。
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.jiuqi.dna.core.internal.db.datasource.PooledConnection.prepareStatement通过 synchronized 关键字，成功获取到了对象的锁，成为监视器的拥有者，在临界区内操作。对象锁是可以线程重入的。
waiting to lock
at com.jiuqi.dna.core.impl.CacheHolder.isVisibleIn(CacheHolder.java:165)- waiting to lock <0x0000000097ba9aa8> (a CacheHolder)at com.jiuqi.dna.core.impl.CacheGroup$Index.findHolderat com.jiuqi.dna.core.impl.ContextImpl.findat com.jiuqi.dna.bap.basedata.common.util.BaseDataCenter.findInfo通过 synchronized 关键字，没有获取到了对象的锁，线程在监视器的进入区等待。在调用栈顶出现，线程状态为 Blocked。
waiting on
at java.lang.Object.wait(Native Method)- waiting on <0x00000000da2defb0> (a WorkingThread)at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo- locked <0x00000000da2defb0> (a WorkingThread)at com.jiuqi.dna.core.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 之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NIO 里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几 乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat 统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制；观察 CPU 的利用率，如果系统态的 CPU 时间，相对于用户态的 CPU 时间比例较高；如果程序运行在 Solaris 10 平台上，可以用 dtrace 工具看系统调用的情况，如果观察到 read/write 的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。（来自http://www.blogjava.net/jzone/articles/303979.html）
二、命令格式
jstack [ option ] pidjstack [ option ] executable corejstack [ 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 长列表。打印关于锁的附加信息，例如属于 java.util.concurrent 的 ownable synchronizers 列表，会使得 JVM 停顿得长久得多（可能会差很多倍，比如普通的 jstack 可能几毫秒和一次 GC 没区别，加了 -l 就是近一秒的时间），-l 建议不要用。一般情况不需要使用
- -m 打印 Java 和 native c/c++ 框架的所有栈信息。可以打印 JVM 的堆栈,显示上 Native 的栈帧，一般应用排查不需要使用
- -h | -help 打印帮助信息
- pid 需要被打印配置信息的 Java 进程 id，可以用 jps 查询。
线程 dump 的分析工具：
IBM Thread and Monitor Dump Analyze for Java 一个小巧的 Jar 包，能方便的按状态，线程名称，线程停留的函数排序，快速浏览。
http://spotify.github.io/threaddump-analyzer Spotify 提供的 Web 版在线分析工具，可以将锁或条件相关联的线程聚合到一起。
三、使用实例
1、jstack pid
~$ jps -mlorg.apache.catalina.startup.Bootstrap ~$ jstack 56612013-04-16 21:09:27Full 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 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104) at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:662)........# jstack -l 4089 >1.txt查看 1.txt 内容如下所示：
2014-03-14 10:47:04Full 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.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) - locked <0x70a84430> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:462) at java.net.ServerSocket.accept(ServerSocket.java:430) at com.sun.tools.hat.internal.server.QueryListener.waitForRequests(QueryListener.java:76) at com.sun.tools.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 java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0x7a2b6f50> (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)
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 java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x7a2b6fe0> (a java.lang.ref.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，尽快定位问题和解决问题
http://www.iteye.com/topic/1114219
1. top 查找出哪个进程消耗的 cpu 高。执行 top 命令，默认是进程视图，其中 PID 是进程号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进程2. top 中shift+h 或 "H" 查找出哪个线程消耗的 cpu 高 先输入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 org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416)
在结果中查找52f1，可看到当前线程在做什么。3、代码示例
运行代码：
public class JStackDemo1 { public static void main(String[] args) { while (true) { //Do Nothing } }}先是有 jps 查看进程号：
hollis@hos:~$ jps29788 JStackDemo129834 Jps22385 org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar然后使用 jstack 查看堆栈信息：
hollis@hos:~$ jstack 297882015-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 的第七行。 看下面代码：
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 java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:503) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) - locked <0x0000000783e066e0> (a java.lang.ref.Reference$Lock)我们能看到：
线程的状态：WAITING 线程的调用栈 线程的当前锁住的资源： <0x0000000783e066e0> 线程当前等待的资源：<0x0000000783e066e0>
为什么同时锁住的等待同一个资源：
线程的执行中，先获得了这个对象的 Monitor（对应于 locked <0x0000000783e066e0>）。当执行到 obj.wait()，线程即放弃了 Monitor的所有权，进入 "wait set" 队列（对应于 waiting on <0x0000000783e066e0> ）。
四、如何分析
1、线程Dump的分析
原则
结合代码阅读的推理。需要线程 Dump 和源码的相互推导和印证。
造成 Bug 的根源往往会在调用栈上直接体现，一定格外注意线程当前调用之前的所有调用。
入手点
进入区等待
"d&a-3588" daemon waiting for monitor entry [0x000000006e5d5000]java.lang.Thread.State: BLOCKED (on object monitor)at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()- waiting to lock <0x0000000602f38e90> (a java.lang.Object)at com.jiuqi.dna.bap.authority.service.UserService$LoginHandler.handle()线程状态 BLOCKED，线程动作 wait on monitor entry，调用修饰 waiting to lock 总是一起出现。表示在代码级别已经存在冲突的调用。必然有问题的代码,需要尽可能减少其发生。
同步块阻塞
一个线程锁住某对象，大量其他线程在该对象上等待。
"blocker" runnablejava.lang.Thread.State: RUNNABLEat com.jiuqi.hcl.javadump.Blocker$1.run(Blocker.java:23)- locked <0x00000000eb8eff68> (a java.lang.Object)"blockee-11" waiting for monitor entryjava.lang.Thread.State: BLOCKED (on object monitor)at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)"blockee-86" waiting for monitor entryjava.lang.Thread.State: BLOCKED (on object monitor)at com.jiuqi.hcl.javadump.Blocker$2.run(Blocker.java:41)- waiting to lock <0x00000000eb8eff68> (a java.lang.Object)持续运行的 IO
IO 操作是可以以 RUNNABLE 状态达成阻塞。例如：数据库死锁、网络读写。格外注意对 IO 线程的真实状态的分析。一般来说，被捕捉到 RUNNABLE 的 IO 调用，都是有问题的。
以下堆栈显示：线程状态为 RUNNABLE。调用栈在 SocketInputStream 或 SocketImpl 上，socketRead0 等方法。调用栈包含了 jdbc 相关的包。很可能发生了数据库死锁
"d&a-614" daemon prio=6 tid=0x0000000022f1f000 nid=0x37c8 runnable[0x0000000027cbd000]java.lang.Thread.State: RUNNABLEat java.net.SocketInputStream.socketRead0(Native Method)at java.net.SocketInputStream.read(Unknown Source)at oracle.net.ns.Packet.receive(Packet.java:240)at oracle.net.ns.DataPacket.receive(DataPacket.java:92)at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:172)at oracle.net.ns.NetInputStream.read(NetInputStream.java:117)at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034)at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:588)分线程调度的休眠
正常的线程池等待
"d&a-131" in Object.wait()java.lang.Thread.State: TIMED_WAITING (on object monitor)at java.lang.Object.wait(Native Method)at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo(WorkingManager.java:322)- locked <0x0000000313f656f8> (a com.jiuqi.dna.core.impl.WorkingThread)at com.jiuqi.dna.core.impl.WorkingThread.run(WorkingThread.java:40)可疑的线程等待
"d&a-121" in Object.wait()java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)at java.lang.Object.wait(Object.java:485)at com.jiuqi.dna.core.impl.AcquirableAccessor.exclusive()- locked <0x00000003011678d8> (a com.jiuqi.dna.core.impl.CacheGroup)at com.jiuqi.dna.core.impl.Transaction.lock()入手点总结
wait on monitor entry： 被阻塞的，肯定有问题
runnable：注意 IO 线程
in Object.wait()：注意非线程池等待
2、死锁分析
如何使用 jstack 分析死锁了也是一定要掌握的内容，看一段死锁的程序：
public class JStackDemo { public static void main(String[] args) { Thread t1 = new Thread(new DeadLockclass(true));//建立一个线程 Thread t2 = new Thread(new DeadLockclass(false));//建立另一个线程 t1.start();//启动一个线程 t2.start();//启动另一个线程 }}class DeadLockclass implements Runnable { public boolean falg;// 控制线程 DeadLockclass(boolean falg) { this.falg = falg; } public void run() { /** * 如果falg的值为true则调用t1线程 */ if (falg) { while (true) { synchronized (Suo.o1) { System.out.println("o1 " + Thread.currentThread().getName()); synchronized (Suo.o2) { System.out.println("o2 " + Thread.currentThread().getName()); } } } } /** * 如果falg的值为false则调用t2线程 */ else { while (true) { synchronized (Suo.o2) { System.out.println("o2 " + Thread.currentThread().getName()); synchronized (Suo.o1) { System.out.println("o1 " + Thread.currentThread().getName()); } } } } }}
class Suo { static Object o1 = new Object(); static Object o2 = new Object();}控制台只输出了两行内容，然后程序就不再打印其它的东西了，但是程序并没有停止。这样就产生了死锁。 当线程 1 使用 synchronized 锁住了 o1 的同时，线程 2 也是用 synchronized 锁住了 o2。当两个线程都执行完第一个打印任务的时候，线程 1 想锁住 o2，线程 2 想锁住 o1。但是，线程 1 当前锁着 o1，线程 2 锁着 o2。所以两个想成都无法继续执行下去，就造成了死锁。
然后，我们使用 jstack 来看一下线程堆栈信息：
Found one Java-level deadlock:============================="Thread-1": waiting to lock monitor 0x00007f0134003ae8 (object 0x00000007d6aa2c98, a java.lang.Object), which is held by "Thread-0""Thread-0": waiting to lock monitor 0x00007f0134006168 (object 0x00000007d6aa2ca8, a java.lang.Object), which is held by "Thread-1"
Java stack information for the threads listed above:==================================================="Thread-1": at javaCommand.DeadLockclass.run(JStackDemo.java:40) - waiting to lock <0x00000007d6aa2c98> (a java.lang.Object) - locked <0x00000007d6aa2ca8> (a java.lang.Object) at java.lang.Thread.run(Thread.java:745)"Thread-0": at javaCommand.DeadLockclass.run(JStackDemo.java:27) - waiting to lock <0x00000007d6aa2ca8> (a java.lang.Object) - locked <0x00000007d6aa2c98> (a java.lang.Object) at java.lang.Thread.run(Thread.java:745)
Found 1 deadlock.堆栈写的很明显，它告诉我们 Found one Java-level deadlock，然后指出造成死锁的两个线程的内容。然后，又通过 Java stack information for the threads listed above 来显示更详细的死锁的信息。
Thread-1在想要执行第40行的时候，当前锁住了资源<0x00000007d6aa2ca8>,但是他在等待资源<0x00000007d6aa2c98>Thread-0在想要执行第27行的时候，当前锁住了资源<0x00000007d6aa2c98>,但是他在等待资源<0x00000007d6aa2ca8> 由于这两个线程都持有资源，并且都需要对方的资源，所以造成了死锁。 原因我们找到了，就可以具体问题具体分析，解决这个死锁了。
其他
虚拟机执行 Full GC 时，会阻塞所有的用户线程。因此，即时获取到同步锁的线程也有可能被阻塞。在查看线程 Dump 时，首先查看内存使用情况。
对于jstack做的 Thread Dump 的栈，可以反映如下信息：
- 如果某个相同的 call stack 经常出现， 我们有 80% 的以上的理由确定这个代码存在性能问题（读网络的部分除外）；
- 如果相同的 call stack 出现在同一个线程上（tid）上，我们很很大理由相信，这段代码可能存在较多的循环或者死循环；
- 如果某 call stack 经常出现， 并且里面带有 lock，请检查一下这个 lock 的产生的原因，可能是全局 lock 造成了性能问题；
- 在一个不大压力的群集里（w < 2），我们是很少拿到带有业务代码的 stack 的，并且一般在一个完整 stack 中，最多只有 1-2 业务代码的 stack，
- 如果经常出现，一定要检查代码，是否出现性能问题。
- 如果你怀疑有 dead lock 问题，那么请把所有的 lock id 找出来，看看是不是出现重复的 lock id。
jstack -m 会打印出 JVM 堆栈信息，涉及 C、C++ 部分代码，可能需要配合 gdb 命令来分析。
频繁GC问题或内存溢出问题
- 使用 jps 查看线程ID
- 使用 jstat -gc 3331 250 20 查看 gc 情况，一般比较关注 PERM 区的情况，查看 GC 的增长情况。
- 使用 jstat -gccause：额外输出上次 GC 原因
- 使用 jmap -dump:format=b,file=heapDump 3331 生成堆转储文件
- 使用 jhat 或者可视化工具（Eclipse Memory Analyzer 、IBM HeapAnalyzer）分析堆情况。
- 结合代码解决内存溢出或泄露问题。
jstack 命令的使用和堆栈分析的更多相关文章
- 【转】java线上程序排错经验2 - 线程堆栈分析
前言 在线上的程序中,我们可能经常会碰到程序卡死或者执行很慢的情况,这时候我们希望知道是代码哪里的问题,我们或许迫切希望得到代码运行到哪里了,是哪一步很慢,是否是进入了死循环,或者是否哪一段代码有问题 ...
- JMX堆栈分析
线程堆栈: 线程堆栈也称线程调用堆栈,是虚拟机中线程(包括锁)状态的一个瞬间快照,即系统在某一个时刻所有线程的运行状态,包括每一个线程的调用堆栈,锁的持有情况.虽然不同的虚拟机打印出来的格式有些不同, ...
- jstack命令的使用
文章来源:https://blog.csdn.net/wufaliang003/article/details/80414267 jstack是java虚拟机自带的一种堆栈跟踪工具. jstack用于 ...
- 【JVM】jvm至jstack命令
一.介绍 jstack是java虚拟机自带的一种堆栈跟踪工具.jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项&qu ...
- jstack 命令学习笔记
大部分内容转载自:Java命令学习系列(二)--Jstack jstack - 查看堆栈信息 jstack ( Stack Trace for java ) 命令主要作用就是为了查看堆栈信息.它可以用 ...
- Java问题定位之Java线程堆栈分析
采用Java开发的大型应用系统越来越大,越来越复杂,很多系统集成在一起,整个系统看起来像个黑盒子.系统运行遭遇问题(系统停止响应,运行越来越慢,或者性能低下,甚至系统宕掉),如何速度命中问题的根本原因 ...
- 给你的Java程序拍个片子吧：jstack命令解析
前言 如果有一天,你的Java程序长时间停顿,也许是它病了,需要用jstack拍个片子分析分析,才能诊断具体什么病症,是死锁综合征,还是死循环等其他病症,本文我们一起来学习jstack命令~ jsta ...
- 使用Tcmalloc进行堆栈分析
在前一篇译文<使用TCmalloc的堆栈检查>,介绍了Tcmalloc进行堆栈检查,今天翻译<heap-profiling using tcmalloc>,了解如何 TCmal ...
- 20145219 gdb调试汇编堆栈分析
20145219 gdb调试汇编堆栈分析 代码gdbdemo.c int g(int x) { return x+19; } int f(int x) { return g(x); } int mai ...
随机推荐
- Javascript实现对象的继承
在Java和C#中,你可以简单的理解class是一个模子,对象就是被这个模子压出来的一批一批月饼.压个啥样,就得是个啥样,不能随便动,动一动就坏了.而在Javascript中,没有模子,月饼被换成了面 ...
- grpc使用客户端技巧
grpc 使用技巧,最近在做的项目是服务端是go语言提供服务使用的是grpc框架. java在实现客户端的时候,参数的生成大部分采用创建者模式.java在接受go服务端 返回数据的时候,更多的是通过p ...
- Python图形编程探索系列-06-按钮批量生产函数
设计任务 初步设计一个批量生产按钮的函数,根据需要的按钮数量,自动生成多少按钮. 函数设计 import tkinter as tk # 导入tkinter库 root = tk.Tk() # 建立程 ...
- django——inclusion_tag
inclusion_tag() 原型: django.template.Library.inclusion_tag() 主要作用:通过渲染一个模板来显示一些数据. 例如,Django的Admin界面使 ...
- gitbook构建文档命令
安装node: sudo ln -s /opt/node-v8.3.9-linux-x64/bin/node /usr/local/bin/node sudo ln -s /opt/node-v8.3 ...
- iOS主流机型更新
主流机型更新后,舍弃了原有的iPhone 4 ,iPhone 4s, iPhone 5 ,iPhone 5s.增加了iPhone X,iPhone 8和iPhone 8 plus. 总体上屏幕趋于一个 ...
- Java基础-多线程-①线程的创建和启动
简单阐释进程和线程 对于进程最直观的感受应该就是“windows任务管理器”中的进程管理: (计算机原理课上的记忆已经快要模糊了,简单理解一下):一个进程就是一个“执行中的程序”,是程序在计算机上的一 ...
- 各种组件的js 获取值 / js动态赋值
jQuery获取Select选择的Text和Value:语法解释:1. $("#select_id").change(function(){//code...}); //为Se ...
- 在iOS端如何使用Charles用作http调试
转:http://blog.csdn.net/messageloop3/article/details/9966727 在iOS端如何使用Charles用作http调试 After noticing ...
- 报错：bash: pip: command not found
$ wget https://bootstrap.pypa.io/get-pip.py$ python get-pip.py$ pip -V #查看pip版本