jdk命令行工具系列——检视阅读（二）

jmap——java内存映射工具

jdk安装后会自带一些小工具，jmap命令(Memory Map for Java)是其中之一。主要用于打印指定Java进程(或核心文件、远程调试服务器)的共享对象内存映射或堆内存细节。

jmap命令可以获得运行中的jvm的堆的快照，从而可以离线分析堆，以检查内存泄漏，检查一些严重影响性能的大对象的创建，检查系统中什么对象最多，各种对象所占内存的大小等等。可以使用jmap生成Heap Dump。

如果不想使用jmap命令，要想获取Java堆转储快照还有一些比较“暴力”的手段：譬如在前面用过的 -XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生成dump文件，通过-XX:+HeapDumpOnCtrlBreak参数可以使用[ctrl]+[Break]键让虚拟机生成dump文件，又或者在Linux系统下通过Kill -3 命令发送进程退出信息“恐吓”一下虚拟机，也能拿到dump文件。

jmap的作用并不仅仅是为了获取dump文件，他还可以查询finalize执行队列，java堆和永久代的详细信息，如空间使用率、当前用的是哪种收集器等。

jmap命令格式

[root@ady01 ~]# jmap
Usage:
    jmap [option] <pid>
        (to connect to running process)
    jmap [option] <executable <core>
        (to connect to a core file)
    jmap [option] [server_id@]<remote server IP or hostname>
        (to connect to remote debug server)

where <option> is one of:
    <none>               to print same info as Solaris pmap
    -heap                to print java heap summary
    -histo[:live]        to print histogram of java object heap; if the "live"
                         suboption is specified, only count live objects
    -clstats             to print class loader statistics
    -finalizerinfo       to print information on objects awaiting finalization
    -dump:<dump-options> to dump java heap in hprof binary format
                         dump-options:
                           live         dump only live objects; if not specified,
                                        all objects in the heap are dumped.
                           format=b     binary format
                           file=<file>  dump heap to <file>
                         Example: jmap -dump:live,format=b,file=heap.bin <pid>
    -F                   force. Use with -dump:<dump-options> <pid> or -histo
                         to force a heap dump or histogram when <pid> does not
                         respond. The "live" suboption is not supported
                         in this mode.
    -h | -help           to print this help message
    -J<flag>             to pass <flag> directly to the runtime system

主要选项：

选项作用
-dump 生成java堆转储快照，格式为：-dump:[live,]format=b,file=<filename>,其中live子参数说明是否只dump出存活对象
-finalizerinfo 显示在F-Queue中等待Finalizer线程执行finalize方法的对象，只在linux/solaris平台下有效
-heap 显示堆详细信息，如使用哪种回收期、参数配置、分带状况等，只在linux/solaris平台下有效
-histo 显示堆中对象统计信息，包括类、实例数量和合计容量
-permstat 以ClassLoader为统计口径显示永久代内存状况，只在linux/solaris平台下有效
-F 当虚拟机进程对-dump选项没有响应时，可以使用这个选项强制生成dump快照，只在linux/solaris平台下有效

jmap -dump：生成java堆转储快照

生成java对转存快照，格式：jmap -dump:[live,]format=b,file=文件名 <pid>

C:\Users\Think>jmap -dump:live,format=b,file=D:/dumptest.hprof 13984
Dumping heap to D:\dumptest.hprof ...
Heap dump file created

可以使用jdk提供的jvisualvm.exe查看hprof文件

jmap -heap：显示堆详细信息

显示堆详细信息。

注意：使用时报错排查原因是由于机器上安装了多个jdk导致的。所以使用时要指定路径。

E:\java8\jdk\bin\jmap -heap 13984

命令格式：jmap -heap <pid>

[root@ady01 ~]# jmap -heap 25867
Attaching to process ID 25867, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.181-b13

using thread-local object allocation.
Parallel GC with 2 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 4164943872 (3972.0MB)
   NewSize                  = 87031808 (83.0MB)
   MaxNewSize               = 1388314624 (1324.0MB)
   OldSize                  = 175112192 (167.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 47710208 (45.5MB)
   used     = 2632072 (2.5101394653320312MB)
   free     = 45078136 (42.98986053466797MB)
   5.516790033696772% used
From Space:
   capacity = 1048576 (1.0MB)
   used     = 770128 (0.7344512939453125MB)
   free     = 278448 (0.2655487060546875MB)
   73.44512939453125% used
To Space:
   capacity = 524288 (0.5MB)
   used     = 0 (0.0MB)
   free     = 524288 (0.5MB)
   0.0% used
PS Old Generation
   capacity = 220200960 (210.0MB)
   used     = 98595728 (94.02821350097656MB)
   free     = 121605232 (115.97178649902344MB)
   44.77533976236979% used

38803 interned Strings occupying 4463232 bytes.

jmap -histo：显示堆中对象统计信息

显示堆中对象统计信息，包括类、实例数量和合计容量

命令格式：jmap -histo[:live] <pid>

C:\Users\Think>jmap -histo 28252

 num     #instances         #bytes  class name
----------------------------------------------
   1:        309006       16963968  [C
   2:          1081        7275840  [I
   3:         41164        3156952  [B
   4:         90125        2163000  java.lang.String
   5:         21000         672000  java.util.UUID
   6:         21000         336000  com.jvm.test8.Test8$User
   7:         21000         336000  com.jvm.test8.Test8$User$UserBuilder
   8:           799         300072  [Ljava.lang.Object;
   9:          7557         181368  java.lang.StringBuilder
  10:           772          87704  java.lang.Class
  11:          1026          65664  sun.nio.fs.WindowsFileAttributes
  12:          1026          49248  sun.nio.fs.WindowsPath$WindowsPathWithAttributes
  13:           837          33480  java.util.TreeMap$Entry
  14:          1032          33024  java.lang.ref.WeakReference
  15:           775          31000  sun.nio.fs.WindowsPath
  16:          1028          24672  sun.nio.fs.WindowsPathParser$Result
  17:           424          13568  java.io.File
  18:           168          12096  java.lang.reflect.Field
  19:           299          11960  java.util.LinkedHashMap$Entry
  20:           323          11200  [Ljava.lang.String;
  21:           173          11072  java.net.URL
  22:           341          10912  sun.misc.FDBigInteger
  23:           312           9984  java.util.Hashtable$Entry
  24:            66           8992  [Ljava.util.HashMap$Node;
  25:           267           8544  java.util.HashMap$Node
  26:           195           7800  java.lang.ref.Finalizer
  27:           264           6336  java.lang.StringBuffer
  28:           121           4840  java.lang.ref.SoftReference
  29:            29           4816  [Ljava.util.Hashtable$Entry;
  30:            50           4800  java.util.jar.JarFile$JarFileEntry
  31:           105           4552  [[C
  32:            53           4240  [Ljava.util.WeakHashMap$Entry;
  33:            74           4144  sun.misc.URLClassPath$JarLoader
  34:           258           4128  java.lang.Integer
  35:            50           4000  java.util.zip.ZipEntry
  36:            79           3792  java.net.NetworkInterface
  37:           150           3600  java.net.Parts
  38:           111           3552  java.util.concurrent.ConcurrentHashMap$Node
  39:           134           3216  java.security.Provider$ServiceKey
  40:            50           3200  java.util.jar.JarFile
  41:            55           3080  sun.nio.cs.UTF_8$Encoder
  42:             8           3008  java.lang.Thread
  43:            62           2976  java.util.HashMap
  44:            51           2856  java.util.zip.ZipFile$ZipFileInputStream
  45:           114           2736  java.io.ExpiringCache$Entry
  46:            53           2544  java.util.WeakHashMap
  47:            30           2400  java.lang.reflect.Constructor
  48:            56           2240  java.util.WeakHashMap$Entry
  49:            39           2184  java.util.zip.ZipFile$ZipFileInflaterInputStream

疑问：

Q: 如何dump堆快照，如何使用jvisualvm.exe查看java进程上dump下来的hprof文件？

A: 首选，我们dump堆快照可以使用jmap命令手动dump下想要获取的堆快照。格式如下：

jmap -dump:[live,]format=b,file=文件名 <pid>

jmap -dump:live,format=b,file=D:/1.hprof 24956

其次，如果不想使用jmap命令，要想获取Java堆转储快照还有一些比较“暴力”的手段：譬如在前面用过的 -XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生成dump文件，通过-XX:+HeapDumpOnCtrlBreak参数可以使用[ctrl]+[Break]键让虚拟机生成dump文件，又或者在Linux系统下通过Kill -3 命令发送进程退出信息“恐吓”一下虚拟机，也能拿到dump文件。

windows使用jvisualvm.exe查看java进程上dump操作如下：

1、进入jdk按照的bin目录打开jvisualvm.exe。

E:\java8\jdk\bin

2、点击文件装入取选取我们dump下的文件位置。注意要更改装入的文件类型为.hprof文件。

3、切换到类选型就可以查看当前dump文件中存活的类占比较大的是什么对象。从而进一步分析内存溢出的原因。

jhat——虚拟机堆转储快照分析工具——一般很少用这个，而是用集成工具

jhat也是jdk内置的工具之一。主要是用来分析java堆的命令，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言。

使用jmap等方法生成java的堆文件后，使用其进行分析

示例：

1.运行代码：

package com.jvm.test8;

import lombok.*;

import java.util.ArrayList;
import java.util.List;
import java.util.UUID;
import java.util.concurrent.TimeUnit;

public class Test8 {
    @Getter
    @Setter
    @ToString
    @Builder
    @NoArgsConstructor
    @AllArgsConstructor
    public static class User {
        private String name;
    }

    public static void main(String[] args) throws InterruptedException {
        List<User> list = new ArrayList<>();
        for (int i = 0; i < 3000; i++) {
            for (int j = 0; j < 1000; j++) {
                list.add(User.builder().name(UUID.randomUUID().toString()).build());
            }
            TimeUnit.SECONDS.sleep(1);
        }
    }
}

2.导出程序执行的堆信息——jmap

F:\fcargitnew\hellospringboot>jps -l
13984
12468 sun.tools.jps.Jps
6324 org.jetbrains.jps.cmdline.Launcher
6908 com.self.test.Test2
8908 org.jetbrains.idea.maven.server.RemoteMavenServer

F:\fcargitnew\hellospringboot>jmap -dump:live,format=b,file=D:/dump.hprof 6908
Dumping heap to D:\dump.hprof ...
Heap dump file created

3.使用jhat分析堆文件

F:\fcargitnew\hellospringboot>jmap -dump:live,format=b,file=D:/dump.hprof 6908
Dumping heap to D:\dump.hprof ...
Heap dump file created

F:\fcargitnew\hellospringboot>jhat D:/dump.hprof
Reading from D:/dump.hprof...
Dump file created Mon Oct 19 11:21:10 CST 2020
Snapshot read, resolving...
Resolving 179681 objects...
Chasing references, expect 35 dots...................................
Eliminating duplicate references...................................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

4.查看html

访问：http://localhost:7000/

分析内存泄露问题主要会用到“Show heap histogram”“”和“OQL”，前者可以找到内存中总容量最大的对象，后者是标准的对象查询语言，使用类似于SQL的语法对内存对象进行查询统计。

显示出堆中所包含的所有的类
从根集能引用到的对象
显示所有类（包括平台）的实例计数
堆实例的分布表
执行对象查询语句

输入内容如：

查询长度大于100的字符串

select s from java.lang.String s where s.count > 100

详细的OQL可点击上图的“OQL help”

jhat中的OQL（对象查询语言） ，文档可以查看：http://localhost:7000/oqlhelp/
如果需要根据某些条件来过滤或查询堆的对象，这是可能的，可以在jhat的html页面中执行OQL，来查询符合条件的对象

基本语法： 
select <javascript expression to select>
[from [instanceof] <class name> <identifier>]
[where <javascript boolean expression to filter>]

解释： 
(1)class name是java类的完全限定名，如：java.lang.String, java.util.ArrayList, [C是char数组, [Ljava.io.File是java.io.File[]
(2)类的完全限定名不足以唯一的辨识一个类，因为不同的ClassLoader载入的相同的类，它们在jvm中是不同类型的
(3)instanceof表示也查询某一个类的子类，如果不明确instanceof，则只精确查询class name指定的类
(4)from和where子句都是可选的
(5)java域表示：obj.field_name；java数组表示：array[index]

举例： 
(1)查询长度大于100的字符串
select s from java.lang.String s where s.count > 100

(2)查询长度大于256的数组
select a from [I a where a.length > 256

(3)显示匹配某一正则表达式的字符串
select a.value.toString() from java.lang.String s where /java/(s.value.toString())

(4)显示所有文件对象的文件路径
select file.path.value.toString() from java.io.File file

(5)显示所有ClassLoader的类名
select classof(cl).name from instanceof java.lang.ClassLoader cl

(6)通过引用查询对象
select o from instanceof 0xd404d404 o

built-in对象 -- heap 
(1)heap.findClass(class name) -- 找到类
select heap.findClass("java.lang.String").superclass

(2)heap.findObject(object id) -- 找到对象
select heap.findObject("0xd404d404")

(3)heap.classes -- 所有类的枚举
select heap.classes

(4)heap.objects -- 所有对象的枚举
select heap.objects("java.lang.String")

(5)heap.finalizables -- 等待垃圾收集的java对象的枚举

(6)heap.livepaths -- 某一对象存活路径
select heaplivepaths(s) from java.lang.String s

(7)heap.roots -- 堆根集的枚举

辨识对象的函数 
(1)classof(class name) -- 返回java对象的类对象
select classof(cl).name from instanceof java.lang.ClassLoader cl

(2)identical(object1,object2) -- 返回是否两个对象是同一个实例
select identical(heap.findClass("java.lang.String").name, heap.findClass("java.lang.String").name)

(3)objectid(object) -- 返回对象的id
select objectid(s) from java.lang.String s

(4)reachables -- 返回可从对象可到达的对象
select reachables(p) from java.util.Properties p -- 查询从Properties对象可到达的对象
select reachables(u, "java.net.URL.handler") from java.net.URL u -- 查询从URL对象可到达的对象，但不包括从URL.handler可到达的对象

(5)referrers(object) -- 返回引用某一对象的对象
select referrers(s) from java.lang.String s where s.count > 100

(6)referees(object) -- 返回某一对象引用的对象
select referees(s) from java.lang.String s where s.count > 100

(7)refers(object1,object2) -- 返回是否第一个对象引用第二个对象
select refers(heap.findObject("0xd4d4d4d4"),heap.findObject("0xe4e4e4e4"))

(8)root(object) -- 返回是否对象是根集的成员
select root(heap.findObject("0xd4d4d4d4")) 

(9)sizeof(object) -- 返回对象的大小
select sizeof(o) from [I o

(10)toHtml(object) -- 返回对象的html格式
select "<b>" + toHtml(o) + "</b>" from java.lang.Object o

(11)选择多值
select {name:t.name?t.name.toString():"null",thread:t} from instanceof java.lang.Thread t

数组、迭代器等函数 
(1)concat(enumeration1,enumeration2) -- 将数组或枚举进行连接
select concat(referrers(p),referrers(p)) from java.util.Properties p

(2)contains(array, expression) -- 数组中元素是否满足某表达式
select p from java.util.Properties where contains(referres(p), "classof(it).name == 'java.lang.Class'")
返回由java.lang.Class引用的java.util.Properties对象
built-in变量
it -- 当前的迭代元素
index -- 当前迭代元素的索引
array -- 被迭代的数组

(3)count(array, expression) -- 满足某一条件的元素的数量
select count(heap.classes(), "/java.io./(it.name)")

(4)filter(array, expression) -- 过滤出满足某一条件的元素
select filter(heap.classes(), "/java.io./(it.name)")

(5)length(array) -- 返回数组长度
select length(heap.classes())

(6)map(array,expression) -- 根据表达式对数组中的元素进行转换映射
select map(heap.classes(),"index + '-->' + toHtml(it)")

(7)max(array,expression) -- 最大值, min(array,expression)
select max(heap.objects("java.lang.String"),"lhs.count>rhs.count")
built-in变量
lhs -- 左边元素
rhs -- 右边元素

(8)sort(array,expression) -- 排序
select sort(heap.objects('[C'),'sizeof(lhs)-sizeof(rhs)')

(9)sum(array,expression) -- 求和
select sum(heap.objects('[C'),'sizeof(it)')

(10)toArray(array) -- 返回数组

(11)unique(array) -- 唯一化数组

jstack——java栈跟踪工具

jstack介绍

jstack（stack trace for java）是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是非常有用的。

So，jstack命令主要用来查看Java线程的调用堆栈的，可以用来分析线程问题（如死锁）。

线程状态

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

NEW：未启动的。不会出现在Dump中。
RUNNABLE：在虚拟机内执行的。运行中状态，可能里面还能看到locked字样，表明它获得了某把锁。
BLOCKED：受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。
WATING：无限期等待另一个线程执行特定操作。等待某个condition或monitor发生，一般停留在park(), wait(),sleep(),join() 等语句里。
TIMED_WATING：有时限的等待另一个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。
TERMINATED：已退出的。

关于线程状态，具体也可以查看：java.lang.Thread.State类。

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 <地址> 目标：park是基本的线程阻塞原语,不通过监视器在对象上阻塞。随concurrent包会出现的新的机制,不synchronized体系不同。

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

jstack命令格式

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’没有响应的时候，强制打印线程堆栈信息，一般情况不需要使用
-l :长列表. 打印关于锁的附加信息，例如属于java.util.concurrent的ownable synchronizers列表，会使得JVM停顿得长久得多（可能会差很多倍，比如普通的jstack可能几毫秒和一次GC没区别，加了-l 就是近一秒的时间），-l 建议不要用，一般情况不需要使用
-m : 打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈，显示上Native的栈帧，一般应用排查不需要使用
-h | -help :打印帮助信息
pid :需要被打印配置信息的java进程id，可以用jps查询

使用示例

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 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)
........

死循环

写个死循环代码
package com.jvm.jstack;

 /**
  * <a href="http://www.itsoku.com/archives">Java干货铺子,只生产干货，公众号：javacode2018</a>
  */
 public class Demo1 {
     public static void main(String[] args) {
         while (true) {
         }
     }
 }

运行代码
cmd中执行jps查看程序进程id
F:\fcargitnew\hellospringboot>jps
13984
11060 Test2
12916 Launcher
396 Jps
8908 RemoteMavenServer

进程id为 11060
输入jstack 11060命令，找到跟我们自己代码相关的线程，如下为main线程，处于runnable状态，在main方法的第8行，也就是我们死循环的位置.
jstack 11060
```
"main" #1 prio=5 os_prio=0 tid=0x0000000002a37000 nid=0x2c50 runnable [0x000000000282f000]
   java.lang.Thread.State: RUNNABLE
        at com.self.test.Test2.main(Test2.java:46)
```

Object.wait()情况

执行下列代码：

package com.jvm.jstack;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

/**
 * <a href="http://www.itsoku.com/archives">Java干货铺子,只生产干货，公众号：javacode2018</a>
 */
public class Demo2 {
    static class TestTask implements Runnable {
        @Override
        public void run() {

            synchronized (this) {
                try {
                    //等待被唤醒
                    wait();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }

        }
    }

    public static void main(String[] args) {
        ExecutorService ex = Executors.newFixedThreadPool(1);
        ex.execute(new TestTask());
    }
}


"From DemoThreadFactory's 订单创建组-Worker-1" #11 prio=5 os_prio=0 tid=0x000000001e476000 nid=0x13f0 in Object.wait() [0x000000001f12e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b798240> (a com.self.test.Test3$TestTask)
        at java.lang.Object.wait(Object.java:502)
        at com.self.test.Test3$TestTask.run(Test3.java:28)
        - locked <0x000000076b798240> (a com.self.test.Test3$TestTask)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

死锁情况

写个死锁的例子
public class TestDeadLock {

    private static Object obj1 = new Object();
    private static Object obj2 = new Object();

    public static void main(String[] args) {
        //自定义饱和策略
        ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 10, 600,
                TimeUnit.SECONDS, new LinkedBlockingQueue<>(5),
                new DemoThreadFactory("订单创建组"), new ThreadPoolExecutor.AbortPolicy());
        // 起10个线程
        for (int i = 0; i < 10; i++) {
            int order = i % 2 == 0 ? 1 : 0;
            executor.execute(new MyRunnable(order));
        }
    }

    static class MyRunnable implements Runnable{
        private int order;

        public MyRunnable( int order) {
            this.order = order;
        }

        public void test1() throws InterruptedException {
            synchronized (obj1) {
                synchronized (obj2) {
                    System.out.println("test1。。。");
                }
            }
        }

        public void test2() throws InterruptedException {
            synchronized (obj2) {
                synchronized (obj1) {
                    System.out.println("test2。。。");
                }
            }
        }

        @Override
        public void run() {
            while (true) {
                try {
                    if (this.order == 1) {
                        this.test1();
                    } else {
                        this.test2();
                    }
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }
}

运行上面代码产生死锁.

我们先通过jsp查找到程序的进程，然后通过jstack查看线程堆栈，很快就可以发现死锁
Found one Java-level deadlock:
=============================
"From DemoThreadFactory's 订单创建组-Worker-10":
waiting to lock monitor 0x000000001c46dfa8 (object 0x000000076b77cf68, a java.lang.Object),
which is held by "From DemoThreadFactory's 订单???建组-Worker-4"
"From DemoThreadFactory's 订单创建组-Worker-4":
waiting to lock monitor 0x000000001c46f448 (object 0x000000076b77cf58, a java.lang.Object),
which is held by "From DemoThreadFactory's 订单创建组-Worker-5"
"From DemoThreadFactory's 订单创建组-Worker-5":
waiting to lock monitor 0x000000001c46dfa8 (object 0x000000076b77cf68, a java.lang.Object),
which is held by "From DemoThreadFactory's 订单创建组-Worker-4"

Java stack information for the threads listed above:
===================================================
"From DemoThreadFactory's 订单创建组-Worker-10":
        at com.self.test.TestDeadLock$MyRunnable.test2(TestDeadLock.java:55)
        - waiting to lock <0x000000076b77cf68> (a java.lang.Object)
        at com.self.test.TestDeadLock$MyRunnable.run(TestDeadLock.java:68)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
"From DemoThreadFactory's 订单创建组-Worker-4":
        at com.self.test.TestDeadLock$MyRunnable.test2(TestDeadLock.java:56)
        - waiting to lock <0x000000076b77cf58> (a java.lang.Object)
        - locked <0x000000076b77cf68> (a java.lang.Object)
        at com.self.test.TestDeadLock$MyRunnable.run(TestDeadLock.java:68)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
"From DemoThreadFactory's 订单创建组-Worker-5":
        at com.self.test.TestDeadLock$MyRunnable.test1(TestDeadLock.java:48)
        - waiting to lock <0x000000076b77cf68> (a java.lang.Object)
        - locked <0x000000076b77cf58> (a java.lang.Object)
        at com.self.test.TestDeadLock$MyRunnable.run(TestDeadLock.java:66)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

等待io

运行代码
public class TestIO {
public static void main(String[] args) throws IOException {
InputStream is = System.in;
int i = is.read();
System.out.println("exit。");
}
}

和上面一样，jps获取进程，jstack获取线程堆栈信息
//长列表. 打印关于锁的附加信息
jstack -l 9168

"main" #1 prio=5 os_prio=0 tid=0x00000000029b7000 nid=0xee0 runnable [0x000000000281f000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(Native Method)
        at java.io.FileInputStream.read(FileInputStream.java:255)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
        - locked <0x000000076b4614f8> (a java.io.BufferedInputStream)
        at com.self.test.TestIO.main(TestIO.java:19)

   Locked ownable synchronizers:
        - None

疑问：

Q: Wait on condition 该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stack trace来分析。最常见的情况就是线程处于sleep状态，等待被唤醒。这应该是wait状态，等待被唤醒，而不是sleep状态吧？