# JVM工具
# jstat
查看堆内存各部分的使用量，以及加载类的数量。
命令格式如下：
jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]
以下转载了网上常用的统计命令
# 类加载统计
jstat -class {pid}
Loaded:加载class的数量 Bytes：所占用空间大小 Unloaded：未加载数量 Bytes:未加载占用空间 Time：时间
# 编译统计
jstat -compiler {pid}
Compiled：编译数量。 Failed：失败数量 Invalid：不可用数量 Time：时间 FailedType：失败类型 FailedMethod：失败的方法
# 垃圾回收统计
jstat -gc {pid}
S0C：第一个幸存区的大小 S1C：第二个幸存区的大小 S0U：第一个幸存区的使用大小 S1U：第二个幸存区的使用大小 EC：伊甸园区的大小 EU：伊甸园区的使用大小 OC：老年代大小 OU：老年代使用大小 MC：方法区大小 MU：方法区使用大小 CCSC:压缩类空间大小 CCSU:压缩类空间使用大小 YGC：年轻代垃圾回收次数 YGCT：年轻代垃圾回收消耗时间 FGC：老年代垃圾回收次数 FGCT：老年代垃圾回收消耗时间 GCT：垃圾回收消耗总时间
# 堆内存统计
jstat -gccapacity {pid}
NGCMN：新生代最小容量 NGCMX：新生代最大容量 NGC：当前新生代容量 S0C：第一个幸存区大小 S1C：第二个幸存区的大小 EC：伊甸园区的大小 OGCMN：老年代最小容量 OGCMX：老年代最大容量 OGC：当前老年代大小 OC:当前老年代大小 MCMN:最小元数据容量 MCMX：最大元数据容量 MC：当前元数据空间大小 CCSMN：最小压缩类空间大小 CCSMX：最大压缩类空间大小 CCSC：当前压缩类空间大小 YGC：年轻代gc次数 FGC：老年代GC次数
# 新生代垃圾回收统计
jstat -gcnew {pid}
S0C：第一个幸存区大小 S1C：第二个幸存区的大小 S0U：第一个幸存区的使用大小 S1U：第二个幸存区的使用大小 TT:对象在新生代存活的次数 MTT:对象在新生代存活的最大次数 DSS:期望的幸存区大小 EC：伊甸园区的大小 EU：伊甸园区的使用大小 YGC：年轻代垃圾回收次数 YGCT：年轻代垃圾回收消耗时间
# 新生代内存统计
jstat -gcnewcapacity {pid}
NGCMN：新生代最小容量 NGCMX：新生代最大容量 NGC：当前新生代容量 S0CMX：最大幸存1区大小 S0C：当前幸存1区大小 S1CMX：最大幸存2区大小 S1C：当前幸存2区大小 ECMX：最大伊甸园区大小 EC：当前伊甸园区大小 YGC：年轻代垃圾回收次数 FGC：老年代回收次数
# 老年代内存统计
jstat -gcoldcapacity {pid}
OGCMN：老年代最小容量 OGCMX：老年代最大容量 OGC：当前老年代大小 OC：老年代大小 YGC：年轻代垃圾回收次数 FGC：老年代垃圾回收次数 FGCT：老年代垃圾回收消耗时间 GCT：垃圾回收消耗总时间
# 元数据空间统计
jstat -gcmetacapacity {pid}
MCMN:最小元数据容量 MCMX：最大元数据容量 MC：当前元数据空间大小 CCSMN：最小压缩类空间大小 CCSMX：最大压缩类空间大小 CCSC：当前压缩类空间大小 YGC：年轻代垃圾回收次数 FGC：老年代垃圾回收次数 FGCT：老年代垃圾回收消耗时间 GCT：垃圾回收消耗总时间
# 总结垃圾回收统计
jstat -gcutil {pid}
S0：幸存1区当前使用比例 S1：幸存2区当前使用比例 E：伊甸园区使用比例 O：老年代使用比例 M：元数据区使用比例 CCS：压缩使用比例 YGC：年轻代垃圾回收次数 FGC：老年代垃圾回收次数 FGCT：老年代垃圾回收消耗时间 GCT：垃圾回收消耗总时间
# JVM编译方法统计
jstat -printcompilation {pid}
Compiled：最近编译方法的数量 Size：最近编译方法的字节码数量 Type：最近编译方法的编译类型。 Method：方法名标识。
# jstack
jstack用于生成java虚拟机当前时刻的线程快照。
jstack能排查什么问题？
- 线程出现长时间停顿（线程间死锁、死循环、请求外部资源导致的长时间等待）
- 排查线程阻塞
- 排查资源耗尽问题（等网络读写、等待数据IO）
线程在堆栈中的状态有：
NEW,未启动的。不会出现在Dump中。
RUNNABLE,在虚拟机内执行的。
BLOCKED,受阻塞并等待监视器锁。
WATING,无限期等待另一个线程执行特定操作。
TIMED_WATING,有时限的等待另一个线程的特定操作。
TERMINATED,已退出的。
堆栈中用于修饰方法调用的内容有：
locked <地址> 目标：使用synchronized申请对象锁成功,监视器的拥有者。
waiting to lock <地址> 目标：使用synchronized申请对象锁未成功,在迚入区等待。
waiting on <地址> 目标：使用synchronized申请对象锁成功后,释放锁幵在等待区等待。
parking to wait for <地址> 目标
堆栈案例解读：
下面列举了一个jstack打印的堆栈信息，并且附有内容释义。
"http-nio-40243-exec-393" #1212 daemon prio=5 os_prio=0 tid=0x00007f4fdc3d9000 nid=0xe30 runnable [0x00007f4fc09d0000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.getStackTraceElement(Native Method)
at java.lang.Throwable.getOurStackTrace(Throwable.java:827)
- locked <0x00000000faf1f990> (a java.lang.Throwable)
at java.lang.Throwable.getStackTrace(Throwable.java:816)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.log4j.spi.LocationInfo.<init>(LocationInfo.java:139)
at org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)
at org.apache.log4j.pattern.LineLocationPatternConverter.format(LineLocationPatternConverter.java:58)
at org.apache.log4j.pattern.BridgePatternConverter.format(BridgePatternConverter.java:119)
at org.apache.log4j.EnhancedPatternLayout.format(EnhancedPatternLayout.java:546)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked <0x00000000e00a2d40> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
- locked <0x00000000e009adf0> (a org.apache.log4j.Logger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
"http-nio-40243-exec-392" #1211 daemon prio=5 os_prio=0 tid=0x00007f4fd8095000 nid=0xe2f waiting for monitor entry [0x00007f4fc0dd4000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:204)
- waiting to lock <0x00000000e009adf0> (a org.apache.log4j.Logger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:230)
at com.navercorp.pinpoint.profiler.logging.Slf4jPLoggerAdapter.debug(Slf4jPLoggerAdapter.java:285)
at com.navercorp.pinpoint.plugin.redis.interceptor.ProtocolSendCommandAndReadMethodInterceptor.before(ProtocolSendCommandAndReadMethodInterceptor.java:71)
线程解读：
- 线程名,“http-nio-40243-exec-393”
- 线程属性（如果是Daemon线程，会有Daemon标识，否则，什么都没有）
- 线程优先级，prio
- java线程对应的本地线程的优先级os_prio
- java线程标识tid
- java线程对应的本地线程标识nid
- 线程状态（运行中、等待等）
- 线程的栈信息
- 线程锁信息
从- locked <0x00000000e009adf0> (a org.apache.log4j.Logger)和- waiting to lock <0x00000000e009adf0> (a org.apache.log4j.Logger)可以看出：
393线程占用了<0x00000000e009adf0>锁，而392线程正等待获取锁。
死锁案例
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.
可以看出两个线程互相等待导致死锁。
# 查看当前java进程的信息
jhsdb必须在jdk11及以上使用 sudo jhsdb jmap --heap --pid xxx
# 字节码工具 asmtools
# jhsdb hsdb
JDK 9加入的调试工具