jps & jstack

本文的初衷仅供自己做备忘笔记, 内容大多从网上搜集和整理, 并非都是自己原创.
参考的来源我会在后面注明, 对于可能遗漏的来源, 还请相关原创作者提醒, 非常感谢.

参考来源:
https://www.cnblogs.com/michael-xiang/p/10779566.html
https://www.iteye.com/blog/crane-ding-968862
https://blog.csdn.net/wufaliang003/article/details/80414267

拜读了三位博主的发文, 感觉很实用, 故记录下来.

java自带的常用工具

JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外， 还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点， 用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测， 先通过一个表格形式简要介绍下这几个命令的作用和使用方法。

命令 作用
jps 基础工具
jstack 查看某个Java进程内的线程堆栈信息
jmap jmap导出堆内存，然后使用jhat来进行分析
jhat 主要用来解析java堆dump并启动一个web服务器，然后就可以在浏览器中查看堆的dump文件
jstat 主要是对java应用程序的资源和性能进行实时的命令行监控，包括了对heap size和垃圾回收状况的监控
hprof hprof能够展现CPU使用率，统计堆内存使用情况

jps

jps 全称 JVM Process Status Tool，命令位于 jdk 的 bin 目录下，其作用是显示当前系统的 Java 进程情况，及其 pid 号。他是 Java自带的一个命令。
jps 命令用来查看所有 Java 进程，每一行就是一个 Java 进程信息。

jps 仅查找当前用户的 Java 进程，而不是当前系统中的所有进程，要显示其他用户的还只能用 ps 命令。

jps 常用参数
第一列的数字就是进程的 pid

  • jps -l
    如果是以 class 方式运行，会显示进程的主类 main.class 的全名，如果是以 jar 包方式运行的，就会输出 jar 包的完整路径名
root@VM-1-3-ubuntu:/home/wechatCrawlerJava# jps
5409 Jps
4172 chapter5-0.0.1-SNAPSHOT.jar
root@VM-1-3-ubuntu:/home/wechatCrawlerJava# jps -l
6629 sun.tools.jps.Jps
4172 ./chapter5-0.0.1-SNAPSHOT.jar
  • jps -v
    输出传递给 JVM 的参数，v 表示虚拟机，jps -vl 比较常见的组合；
  • jps -V
    大写 v，表示通过文件传递给 JVM 的参数
# michael @ Michael-MBP in ~ [16:37:59]
$ jps -v |grep Mybatis
8005 MybatisDemoApplication -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:53364,suspend=y,server=n -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=53363 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=127.0.0.1 -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -javaagent:/Users/michael/Library/Caches/IntelliJIdea2018.2/captureAgent/debugger-agent.jar=file:/private/var/folders/m1/ydypchs901lffc5sms07mrp40000gn/T/capture.props -Dfile.encoding=UTF-8
  • jps -m
    输出传递给 main.class 方法的参数，实用的一个命令，jps -ml 比较实用的组合，会显示包名/类名/参数
  • jps -q
    只输出进程的 pid

jstack

简介

jstack是java虚拟机自带的一种堆栈跟踪工具。
jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。
jstack命令主要用来查看Java线程的调用堆栈的，可以用来分析线程问题（如死锁）。

jstack命令

Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -m  to print both java and native frames (mixed mode)
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

-F 当’jstack [-l] pid’没有相应的时候强制打印栈信息,如果直接jstack无响应时，用于强制jstack，一般情况不需要使用
-l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表，会使得JVM停顿得长久得多 （可能会差很多倍，比如普通的jstack可能几毫秒和一次GC没区别，加了-l 就是近一秒的时间），-l 建议不要用。一般情况不需要使用
-m 打印java和native c/c++ 框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧，一般应用排查不需要使用

执行命令：

 jstack -m 12905

线程状态

想要通过jstack命令来分析线程的情况的话，首先要知道线程都有哪些状态，下面这些状态是我们使用jstack命令查看线程堆栈信息时可能会看到的线程的几种状态：

  • NEW,未启动的。不会出现在Dump中。
  • RUNNABLE,在虚拟机内执行的。
  • BLOCKED,受阻塞并等待监视器锁。
  • WATING,无限期等待另一个线程执行特定操作。
  • TIMED_WATING,有时限的等待另一个线程的特定操作。
  • TERMINATED,已退出的。

Monitor

在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。 Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。下 面这个图，描述了线程和 Monitor之间关系，以 及线程的状态转换图：


7e99e25b.png
  • 进入区(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.findHolder
at com.jiuqi.dna.core.impl.ContextImpl.find
at 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之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几 乎消耗了所有的带宽，仍然有大量数据等待网络读 写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。

死锁例子

jstack [-l] <pid>, pid可以通过使用jps命令来查看当前Java程序的pid值,-l是可选参数,它可以显示线程阻塞/死锁情况。

/** 
 * 死锁例子 
 * @author crane.ding 
 * @since 2011-3-20 
 */  
public class DeadLock {  

    public static void main(String[] args) {  
        final Object obj_1 = new Object(), obj_2 = new Object();  

        Thread t1 = new Thread("t1"){  
            @Override  
            public void run() {  
                synchronized (obj_1) {  
                    try {  
                        Thread.sleep(3000);  
                    } catch (InterruptedException e) {}  

                    synchronized (obj_2) {  
                        System.out.println("thread t1 done.");  
                    }  
                }  
            }  
        };  

        Thread t2 = new Thread("t2"){  
            @Override  
            public void run() {  
                synchronized (obj_2) {  
                    try {  
                        Thread.sleep(3000);  
                    } catch (InterruptedException e) {}  

                    synchronized (obj_1) {  
                        System.out.println("thread t2 done.");  
                    }  
                }  
            }  
        };  

        t1.start();  
        t2.start();  
    }  
}

以上DeadLock类是一个死锁的例子,假使在我们不知情的情况下,运行DeadLock后,发现等了N久都没有在屏幕打印线程完成信息。这个时候我们就可以使用jps查看该程序的jpid值和使用jstack来生产堆栈结果问题。

$ java -cp deadlock.jar DeadLock &  
$   

$ jps  
  3076 Jps  
  448 DeadLock  
$ jstack -l 448 > deadlock.jstack

结果文件deadlock.jstack内容如下：

2011-03-20 23:05:20  
Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode, sharing):  

"DestroyJavaVM" prio=6 tid=0x00316800 nid=0x9fc waiting on condition [0x00000000]  
   java.lang.Thread.State: RUNNABLE  

   Locked ownable synchronizers:  
    - None  

"t2" prio=6 tid=0x02bcf000 nid=0xc70 waiting for monitor entry [0x02f6f000]  
   java.lang.Thread.State: BLOCKED (on object monitor)  
    at com.demo.DeadLock$2.run(DeadLock.java:40)  
    - waiting to lock <0x22a297a8> (a java.lang.Object)  
    - locked <0x22a297b0> (a java.lang.Object)  

   Locked ownable synchronizers:  
    - None  

"t1" prio=6 tid=0x02bce400 nid=0xba0 waiting for monitor entry [0x02f1f000]  
   java.lang.Thread.State: BLOCKED (on object monitor)  
    at com.demo.DeadLock$1.run(DeadLock.java:25)  
    - waiting to lock <0x22a297b0> (a java.lang.Object)  
    - locked <0x22a297a8> (a java.lang.Object)  

   Locked ownable synchronizers:  
    - None  

"Low Memory Detector" daemon prio=6 tid=0x02bb9400 nid=0xa6c runnable [0x00000000]  
   java.lang.Thread.State: RUNNABLE  

   Locked ownable synchronizers:  
    - None  

"CompilerThread0" daemon prio=10 tid=0x02bb2800 nid=0xcb8 waiting on condition [0x00000000]  
   java.lang.Thread.State: RUNNABLE  

   Locked ownable synchronizers:  
    - None  

"Attach Listener" daemon prio=10 tid=0x02bb1000 nid=0x7f4 waiting on condition [0x00000000]  
   java.lang.Thread.State: RUNNABLE  

   Locked ownable synchronizers:  
    - None  

"Signal Dispatcher" daemon prio=10 tid=0x02bd2800 nid=0xd80 runnable [0x00000000]  
   java.lang.Thread.State: RUNNABLE  

   Locked ownable synchronizers:  
    - None  

"Finalizer" daemon prio=8 tid=0x02bab000 nid=0xe1c in Object.wait() [0x02d3f000]  
   java.lang.Thread.State: WAITING (on object monitor)  
    at java.lang.Object.wait(Native Method)  
    - waiting on <0x229e1148> (a java.lang.ref.ReferenceQueue$Lock)  
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)  
    - locked <0x229e1148> (a java.lang.ref.ReferenceQueue$Lock)  
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)  
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)  

   Locked ownable synchronizers:  
    - None  

"Reference Handler" daemon prio=10 tid=0x02ba6800 nid=0xbe0 in Object.wait() [0x02cef000]  
   java.lang.Thread.State: WAITING (on object monitor)  
    at java.lang.Object.wait(Native Method)  
    - waiting on <0x229e1048> (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 <0x229e1048> (a java.lang.ref.Reference$Lock)  

   Locked ownable synchronizers:  
    - None  

"VM Thread" prio=10 tid=0x02b6a400 nid=0x568 runnable   

"VM Periodic Task Thread" prio=10 tid=0x02bc8400 nid=0x75c waiting on condition   

JNI global references: 878  


Found one Java-level deadlock:  
=============================  
"t2":  
  waiting to lock monitor 0x02baaeec (object 0x22a297a8, a java.lang.Object),  
  which is held by "t1"  
"t1":  
  waiting to lock monitor 0x02baa2bc (object 0x22a297b0, a java.lang.Object),  
  which is held by "t2"  

Java stack information for the threads listed above:  
===================================================  
"t2":  
    at com.demo.DeadLock$2.run(DeadLock.java:40)  
    - waiting to lock <0x22a297a8> (a java.lang.Object)  
    - locked <0x22a297b0> (a java.lang.Object)  
"t1":  
    at com.demo.DeadLock$1.run(DeadLock.java:25)  
    - waiting to lock <0x22a297b0> (a java.lang.Object)  
    - locked <0x22a297a8> (a java.lang.Object)  

Found 1 deadlock.

从这个结果文件我们一看到发现了一个死锁,具体是线程t2在等待线程t1,而线程t1在等待线程t2造成的,同时也记录了线程的堆栈和代码行数,通过这个堆栈和行数我们就可以去检查对应的代码块,从而发现问题和解决问题。

©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容