jdk命令行工具系列——检视阅读
参考
java虚拟机系列
RednaxelaFX知乎问答
RednaxelaFX博客
jps——虚拟机进程状态工具
jps :(JVM Process Status Tool)：虚拟机进程状态工具，可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class，main()函数所在的类）的名称，以及这些进程的本地虚拟机的唯一ID（LVMID,Local Vitual Machine Identifier）,它是使用频率最高的JDK命令行工具，因为其他JDK工具大多需要输入它查询到的LVMID来确定要监控的是哪一个虚拟机进程。
对于本地虚拟机进程来说，LVMID与操作系统进程ID（PID，Process Identifier）是一致的。
如果同时启动了多个虚拟机进程，无法根据进程名称定位时，那就只能依靠jps命令显示主类的功能才能区分了。
jps命令格式:
jps options
jps执行样例
jps工具主要选项
选项 作用
-q 只输出LVMID,省略主类的名称
-m 输出虚拟机进程启动时传递给main()函数的参数
-l 输出主类的全名，如果进程执行的是jar包，输出jar路径
-v 输出虚拟机进程启动时JVM参数
jps -q
只输出LVMID，省略主类的名称
jps -m
输出虚拟机进程启动时传递给main()函数的参数
jps -l
输出主类的全名，如果进程执行的是jar包，输出jar路径。
jar包的情况
jps -v
输出虚拟机进程启动时JVM参数
jstat——虚拟机统计信息监控工具
jstat（JVM Statistics Monitorning Tool）
用于监控虚拟机各种运行状态信息的命令行工具。
它可以显示本地或远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据，它是运行期定位虚拟机性能问题的首选工具。
语法：
参数 interval 和 count 代表查询间隔和次数，如果省略这两个参数，说明只查询一次。假如需要每250毫秒查询一次进程2764垃圾收集的情况，一共查询20次，那么命令应该是：jstat -gc 2764 250 20
主要选项
选项 作用
-class 监视类装载、卸载数量、总空间及类装载所耗费的时间
-gc 监视Java堆状况，包括Eden区、2个Survivor区、老年代、永久代等容量、已用空间、GC合计时间等信息
-gccapacity 监视内容与-gc基本相同，但输出主要关注java堆各区域使用到的最大和最小空间
-gcutil 监控内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比
-gccause 与-gcutil功能一样，但是会额外输出导致上一次GC产生的原因
-gcnew 监视新生代GC的状况
-gcnewcapacity 监视内容与-gcnew基本相同，输出主要关注使用到的最大和最小空间
-gcold 监视老年代GC的状况
-gcoldcapacity 监视内容与-gcold基本相同，输出主要关注使用到的最大和最小空间
-gcpermcapacity 输出永久代使用到的最大和最小空间
-compiler 输出JIT编译器编译过的方法、耗时等信息
-printcompilation 输出已被JIT编译的方法
统计加载类的信息
命令：jstat -class
列名 说明
Loaded 装载的类的数量
Bytes 装载类所占用的字节数
Unloaded 卸载类的数量
Bytes 卸载类所占用的字节数
Time 装载类和卸载类所耗费的时间(毫秒)
编译统计
命令：jstat -compiler pid
列名 说明
Compiled 编译任务执行数量
Failed 编译任务执行失败的数量
Invalid 编译任务失效的数量
Time 编译总耗时（毫秒）
FailedType 最后一个编译失败任务的类型
FailedMethod 最后一个编译失败任务所在的类及方法
垃圾回收统计——GC的各区域容量和已使用容量、GC次数及消耗时间
命令：jstat -gc
列名 说明
S0C 年轻代中第一个survior（幸存区）的容量（kb）
S1C 年轻代中第二个survior（幸存区）的容量（kb）
S0U 年轻代中第一个survior（幸存区）目前已使用的容量（kb）
S1U 年轻代中第二个survior（幸存区）目前已使用的容量（kb）
EC eden区的容量（kb）:eden capacity
EU eden区目前已使用的容量（kb）:eden used
OC 老年代的容量（kb）:old capacity
OU 老年代目前已使用的容量（kb）
PC perm永久代的容量（kb）
PU perm永久代目前已使用的容量（kb）
YGC 从应用程序启动到采集时年轻代中gc次数
YGCT 从应用程序启动到采集时年轻代中gc所用总时间（秒）
FGC 从应用程序启动到采集时老年代中gc次数
FGCT 从应用程序启动到采集时老年代gc所用的总时间（秒）
GCT 从应用程序启动到采集时gc所用的总时间（秒）
CCSC 压缩类空间容量（KB） compact class space capacity ,jdk1.8
CCSU 压缩空间目前已使用大小（KB） ,jdk1.8
MC 元空间的容量（KB） Metaspace capacity,jdk1.8的方法区不再是永久代实现，而是元空间
MU 元空间目前已使用大小（KB） ,jdk1.8
统计gc信息——关注各区域已使用空间占总空间的百分比
命令：jstat -gcutil
S0 年轻代中第一个（survisor）幸存区已使用的容量占比
S1 年轻代中第二个（survisor）幸存区已使用的容量占比
E 伊旬园（eden）区已使用的容量占比
O 老年代区已使用的容量占比
P 永久代（perm）已使用的容量占比
YGC 年轻代到目前gc次数
YGCT 年轻代到目前gc耗费的总时间（秒）
FGC 老年代目前gc次数
FGCT 老年代目前gc耗费的总时间（秒）
GC 从应用程序到目前gc总耗时（秒）
M 元空间（metaspace）已使用的容量占比,jdk1.8后方法区用元空间实现
CCS 压缩类空间已使用的容量占比
堆内存统计——主要关注java堆各区域使用到的最大和最小空间
命令：jstat -gccapacity
列名 说明
NGCMN 年轻代（young）中初始化（最小）的大小（kb）
NGCMX 年轻代（young）中初始化（最大）的大小（kb）
NGC 年轻代（young）中当前的容量（kb）
S0C 年轻代中第一个（survisor）幸存区的容量（kb）
S1C 年轻代中第二个（survisor）幸存区的容量（kb）
EC 年轻代中（Eden)伊旬园的容量（kb）
OGCMN 老年代（old）中初始化（最小）的容量（kb）
OGCMX 老年代（old）中初始化（最大）的容量（kb）
OGC 当前老年代的大小（kb）
OC 当前老年代的大小（kb）
PGCMN 永久代（perm）中初始化（最小）的大小（kb）
PGCMX 永久代（perm）中初始化（最大）的大小（kb）
PGC 永久代当前的大小（kb）
PC 永久代当前的大小（kb）
YGC 从应用程序启动到采集时年轻代gc的次数
FGC 从应用程序启动带采集时老年代gc的次数
MCMN 元空间（metaspace）中初始化（最小）的大小（kb）,jdk1.8后方法区用元空间实现
MCMX 元空间（metaspace）中初始化（最大）的大小（kb）,jdk1.8
MC 元空间当前的大小（kb）,jdk1.8
CCSMN 压缩类空间中初始化（最小）的大小（kb）,jdk1.8
CCSMX 压缩类空间中初始化（最大）的大小（kb）,jdk1.8
CCSC 压缩类空间当前的大小（kb）,jdk1.8
新生代垃圾回收统计——监视新生代GC的状况
命令：jstat -gcnew
S0C 年轻代中第一个（survisor）幸存区的容量（kb）
S1C 年轻代中第二个（survisor）幸存区的容量（kb）
S0U 年轻代中第一个（survisor）幸存区目前已使用的容量（kb）
S1U 年轻代中第二个（survisor）幸存区目前已使用的容量（kb）
TT 对象在新生代中存活的次数
MTT 对象在新生代中存活的最大次数
DSS 当前需要survivor(幸存区)的容量 (kb)（Eden区已满）
EC 伊旬园（eden）区的大小（kb）
EU 伊旬园（eden）区已使用的大小（kb）
YGC 到目前年轻代gc的次数
YGCT 到目前年轻代gc所耗费的时间（秒）
新生代内存统计——主要关注新生代使用到的最大和最小空间
命令：jstat -gcnewcapacity
NGCMN 年轻代中初始化最小容量（kb）
NGCMX 年轻代中初始化最大容量（kb）
NGC 年轻代当前容量（kb）
S0CMX 年轻代第一个幸存区（survisor）最大容量（kb）
S0C 年轻代第一个幸存区（survisor）当前容量（kb）
S1CMX 年轻代第二个幸存区（survisor）最大容量（kb）
S1C 年轻代第二个幸存区（survisor）当前容量（kb）
ECMX 年轻代伊旬园区（Eden）最大容量（kb）
EC 年轻代伊旬园区（Eden）当前容量（kb）
YGC 截止到目前年轻代gc次数
FGC 截止到目前老年代gc次数
老年代垃圾回收统计——监视老年代GC的状况
命令：jstat -gcold
PC 永久区（perm）容量（kb）
PU 永久区（perm）已使用容量（kb）
OC 老年代容量（kb）
OU 老年代已使用容量（kb）
YGC 截止到目前年轻代gc次数
FGC 截止到目前老年代gc次数
GCT 截止到目前gc耗费的总时间（秒）
MC 元空间容量（kb）,jdk1.8后方法区用元空间实现
MU 元空间已使用容量（kb）,jdk1.8
CCSC 压缩类空间容量（kb）,jdk1.8
CCSU 压缩类空间已使用容量（kb）,jdk1.8
老年代内存统计——关注老年代使用到的最大和最小空间
命令：jstat -gcoldcapacity
OGCMN 老年代最小容量（kb）
OGCMX 老年代最大容量（kb）
OGC 老年代目前生成的容量（kb）：表示目前老年代的全部容量（容量或根据需要变化）
OC 老年代目前容量（kb）
FGCT 截止到目前老年代gc耗费的总时间（秒）
GCT 截止到目前gc耗费的总时间（秒）
永久代内存统计——永久代使用到的最大和最小空间
命令：jstat -gcpermcapacity
如果是jdk1.8使用 jstat -gcmetacapacity 9884 1000 3
PGCMN 永久代最小容量（kb）
PGCMX 永久代最大容量（kb）
PGC 永久代当前生成的容量（kb）:perm general capacity :永久代总的容量
PC 永久代当前容量（kb）
YGC 截止目前年轻代gc次数
FGC 截止目前老年代gc次数
FGCT 截止目前年轻代gc耗费的总时间（秒）
GCT 截止目前老年代gc耗费的总时间（秒）
最近二次gc统计——主要关注已使用空间占总空间的百分比 ，会额外输出导致上一次GC产生的原因
命令：gstat -gccause
LGCC 最近垃圾回收的原因
GCC 当前垃圾回收的原因
JVM编译方法统计
命令：jstat -printcompilation
Compiled 最近编译方法的数量
Size 最近编译方法的字节码数量？单位呢？
Type 最近编译方法的编译类型
Method 方法名标识
疑问：
Q: 如下linux的命令行格式如何理解，尖括号和中括号表示什么意思？
Q:老年代（old）中初始化（最小）的容量（kb）,这个初始化怎么理解？是不是只一开始分配的空间大小和后面动态扩容空间后的容量大小？
Q:当操作 jstat -gcnew pid 时，对于显示出来的下面这3个值要怎么理解？TT 对象在新生代中存活的次数是指哪部分的对象，是指当前所有存活的对象中，其中存活时间最久的那个对象在新生代中存活的次数么？而对象在新生代中存活的最大次数是指从启动到目前为止历史上对象在对象在新生代中存活的最大次数么？当前需要survivor(幸存区)的容量 (kb)是指什么？是指上一次eden区满时需要的survivor(幸存区)的容量大小是么？
TT 对象在新生代中存活的次数 MTT 对象在新生代中存活的最大次数 DSS 当前需要survivor(幸存区)的容量 (kb)（Eden区已满）
Q: CCSC:压缩类空间是什么意思？
A: 参考
这是java1.8后把方法区的实现从永久代改为元空间实现后有的概念，Java8在UseCompressedOops之外，额外增加了一个新选项叫做UseCompressedClassPointer。这个选项打开后，class信息中的指针也用32bit的Compressed版本。而这些指针指向的空间被称作“Compressed Class Space”。默认大小是1G，但可以通过“CompressedClassSpaceSize”调整。是给元空间使用的。
如果你的java程序引用了太多的包，有可能会造成这个空间不够用，于是会看到
这时，一般调大CompreseedClassSpaceSize就可以了。
扩展作者回答：
在Java8以前，有一个选项是UseCompressedOops：使用压缩原始指针。所谓OOPS是指“ordinary object pointers“，就是原始指针。Java Runtime可以用这个指针直接访问指针对应的内存，做相应的操作（比如发起GC时做copy and sweep）。
那么Compressed是啥意思？64bit的JVM出现后，OOPS的尺寸也变成了64bit，比之前的大了一倍。这会引入性能损耗——占的内存double了，并且同尺寸的CPU Cache要少存一倍的OOPS。
于是就有了UseCompressedOops这个选项。打开后，OOPS变成了32bit。但32bit的base是8，所以能引用的空间是32GB——这远大于目前经常给jvm进程内存分配的空间。
一般建议不要给JVM太大的内存，因为Heap太大，GC停顿实在是太久了。所以很多开发者喜欢在大内存机器上开多个JVM进程，每个给比如最大8G以下的内存。
从JDK6_u23开始UseCompressedOops被默认打开了。因此既能享受64bit带来的好处，又避免了64bit带来的性能损耗。当然，如果你有机会使用超过32G的堆内存，记得把这个选项关了。
到了Java8，永久代被干掉了，有了“meta space”的概念，存储jvm中的元数据，包括byte code，class等信息。Java8在UseCompressedOops之外，额外增加了一个新选项叫做UseCompressedClassPointer：使用压缩类指针。这个选项打开后，class信息中的指针也用32bit的Compressed版本。而这些指针指向的空间被称作“Compressed Class Space”。默认大小是1G，但可以通过“CompressedClassSpaceSize”调整。
-XX:+UseCompressedClassPointers 是需要 -XX:+UseCompressedOops 开启的，所以堆大小要是大于 32G，CompressedOops 自动关闭，CompressedClassPointers 也会关闭的，关闭了就没有 Compressed Class Space 了，这块就是 Class Space 了。
-XX:CompressedClassSpaceSize 大小的设置也是有限制，因为压缩开关是受制于 32G，所以这个自然也是不能大于 32G，不过 hotspot 规定了这个参数不准大于 3G，所以这个参数其实是不能大于 3G。
一般来说，平均一个 Klass 大小可以当成 1K 来算，默认的 1G 大小可以存储 100 万的 Klass。如果遇到了 java.lang.OutOfMemoryError: Compressed class space，就是类太多了，需要结合具体情况去选择 JVM 调优还是 bug 排查。
jinfo——jvm配置信息工具
jinfo（Configuration Info for Java）的作用是实时地查看和调整虚拟机的各项参数。
使用jps -v 可以查看虚拟机启动时显示指定的参数列表，但是如果想知道未被显示指定的参数的系统默认值，可以使用jinfo的-flag选项进行查询了。
jinfo -flags
——打印所有的jvm标志信息
注意打印所有的jvm标志信息要用 -flags
Non-default VM flags: 非默认VM标志
Command line: 命令行中指定的jvm参数
jinfo -flag
—— 打印指定的jvm参数信息
jinfo -flag [+|-]
——启用或者禁用指定的jvm参数
我们运行一段程序，下面这段程序vm参数设置为:-Xms5m -Xmx5m,运行过程中会参数OOM，在运行过程中，我们添加vm参数：+HeapDumpOnOutOfMemoryError：发生OOM的时候，让程序打印堆dump文件
运行过程中添加参数
程序运行结果：
jinfo -flag =
——给指定的jvm参数设置值
注意很多堆等内存大小值是不能设置的，dump内存可以设置。
jinfo -sysprops
——打印系统参数信息
打印的信息和System.getProperties()一样。
jinfo
——打印以上所有配置信息
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命令格式
主要选项：
选项 作用
-dump 生成java堆转储快照，格式为：-dump:[live,]format=b,file=,其中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=文件名
可以使用jdk提供的jvisualvm.exe查看hprof文件
jmap -heap：显示堆详细信息
显示堆详细信息。
注意：使用时报错排查原因是由于机器上安装了多个jdk导致的。所以使用时要指定路径。
命令格式：jmap -heap
jmap -histo：显示堆中对象统计信息
显示堆中对象统计信息，包括类、实例数量和合计容量
命令格式：jmap -histo[:live]
Q: 如何dump堆快照，如何使用jvisualvm.exe查看java进程上dump下来的hprof文件？
A: 首选，我们dump堆快照可以使用jmap命令手动dump下想要获取的堆快照。格式如下：
jmap -dump:[live,]format=b,file=文件名
其次，如果不想使用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。
2、点击文件装入取选取我们dump下的文件位置。注意要更改装入的文件类型为.hprof文件。
3、切换到类选型就可以查看当前dump文件中存活的类占比较大的是什么对象。从而进一步分析内存溢出的原因。
jhat——虚拟机堆转储快照分析工具——一般很少用这个，而是用集成工具
jhat也是jdk内置的工具之一。主要是用来分析java堆的命令，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言。
使用jmap等方法生成java的堆文件后，使用其进行分析
示例：
1.运行代码：
2.导出程序执行的堆信息——jmap
3.使用jhat分析堆文件
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”
jstack——java栈跟踪工具
jstack介绍
jstack（stack trace for java）是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使用方式只支持以下的这种方式：
主要分为两个功能：
针对活着的进程做本地的或远程的线程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就像：
调用修饰
表示线程在方法调用时,额外的重要的操作。线程Dump分析的重要信息。修饰上方的方法调用。
locked <地址> 目标：使用synchronized申请对象锁成功,监视器的拥有者。
waiting to lock <地址> 目标：使用synchronized申请对象锁未成功,在进入区等待。
waiting on <地址> 目标：使用synchronized申请对象锁成功后,释放锁并在等待区等待。
parking to wait for <地址> 目标：park是基本的线程阻塞原语,不通过监视器在对象上阻塞。随concurrent包会出现的新的机制,不synchronized体系不同。
locked
通过synchronized关键字，成功获取到了对象的锁，成为监视器的拥有者，在临界区内操作。对象锁是可以线程重入的。
waiting to lock
通过synchronized关键字，没有获取到了对象的锁，线程在监视器的进入区等待。在调用栈顶出现，线程状态为Blocked。
waiting on
通过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命令格式
常用参数说明
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
死循环
写个死循环代码
package com.jvm.jstack;
运行代码
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
Object.wait()情况
执行下列代码：
死锁情况
写个死锁的例子
public class TestDeadLock {
运行上面代码产生死锁.
我们先通过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":
which is held by "From DemoThreadFactory's 订单创建组-Worker-4"
等待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
Q: Wait on condition 该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stack trace来分析。 最常见的情况就是线程处于sleep状态，等待被唤醒。 这应该是wait状态，等待被唤醒，而不是sleep状态吧？