1.GC日志

Java应用程序的GC日志对分析定位很多性能问题有着非常大的帮助。默认情况下，Java应用程序不会自动产生GC日志。如果需要输出GC日志，必须在JVM启动时增加对应的参数。

上图是JVM中一次年老代内存区域GC垃圾回收的输出日志。“[Full GC (Metadata GC Threshold)[PSYoungGen: 14355K->0K(274432K)][ParOldGen: 39413K->32862K(83456K)]53769K->32862K(357888K)，[Metaspace:20699K->20699K(1069056K)]，0.1843152 secs][Times: user=0.62 sys=0.00，real=0.18 secs]”描述了Full GC发生的原因是Metadata GC Threshold（元数据超过了元数据区域的GC阈值）、年轻代内存使用从14355KB减少为0KB（[PSYoungGen:14355K->0K(274432K)]）、年老代内存使用从39413KB减少为32862KB（[ParOldGen: 39413K->32862K(83456K)]）、堆内存的总使用从53769KB减少为32862KB（53769K->32862K(357888K)）、元数据空间内存的使用从20699KB减少为20699KB（[Metaspace: 20699K->20699K(1069056K)]）、Full GC耗时0.1843152秒、用户耗时0.62秒、系统耗时0.00秒、实际耗时0.18秒。从中也可以看出Full GC对用户线程耗时的影响非常大，这就是为什么需要尽量去减少Full GC的原因。

2.线程堆栈

jstack是用于查看JVM线程堆栈的常用工具命令，通过jstack可以获取每个线程内部的调用链以及每个线程当前的运行状态从而可以分析死锁、死循环、响应慢等很多常见的性能问题

上图是以main()方法线程："main" #1 prio=5 os_prio=0 tid=0x0000000001e5e800 nid=0x3870 runnable[0x000000000292e000]为例来说明线程堆栈中包含的信息，其中tid=0x0000000001e5e800代表了JVM中的线程id，这个是JVM虚拟机根据一定规则生成的一个不重复的线程标志。nid=0x3870代表了本地线程id，也就是操作系统中线程id。这个线程id是用16进制来表示的，0x3870转换成10进制对应的id就是14448。

下图是通过线程堆栈定位问题的步骤

通过线程堆栈定位一些常见问题的方式如下：

（1）JVM进程CPU占用率非常高，请求响应非常慢。

在一个请求被应用程序执行的过程中，多次对JVM进程生成线程堆栈，对比每次线程堆栈中状态为runnable的线程执行的方法是否一样，如果每次都是执行同一个方法，说明这个方法非常占用CPU，并且非常耗时，需要进行优化。如果每次不是在执行同一个方法，可以看一下总共执行了哪些方法，如果方法过多，说明是请求在应用程序中执行的方法过多。

（2）JVM进程CPU占用率不高，请求响应非常慢。

在一个请求被应用程序执行的过程中，多次对JVM进程生成线程堆栈，对比每次线程堆栈中的日志，查看是否线程都出现了类似I/O、数据库查询等待的情况，通过线程堆栈日志定位线程是否一直在等待被占用的其他资源。

（3）请求一直无法被响应。

在一个请求被应用程序执行的过程中，多次对JVM进程生成线程堆栈，对比每次线程堆栈中的日志，查看是否所有的runnable线程都一直在执行相同的方法，若是如此，就说明可能出现了死锁。在发现出现死锁后，可以通过线程堆栈中当前所运行的代码做进一步的分析，确定是在争抢何种资源时导致了死锁。