概要
Java 性能剖析是一门艺术和迷信。迷信指的是性能剖析个别都包含大量的数字、测量和剖析；艺术指的是常识、教训和直觉的应用。性能剖析的工具或者伎俩各有千秋，但性能的剖析的过程却都天壤之别。本文就已知实用的 Java 性能剖析诀窍进行一些分享，帮忙用户更好的了解和使用。
诀窍一：线程栈分析
线程栈剖析是对正在运行的 Java 线程的快照剖析，是一种轻量级的剖析伎俩，用户在不分明利用存在什么性能问题的时候可优先尝试。尽管断定 Java 线程是否异样并没有对立的规范，但用户能够通过一些指标进行定量的评估。以下分享 4 个检测指标：
1)线程死锁查看
线程死锁查看是一个十分有价值的检测指标。如果线程死锁，则个别存在系统资源的节约或服务能力降落等问题，一旦发现就须要及时处理。线程死锁检测会展现线程死锁关系以及对应的栈信息，通过剖析即可定位到触发死锁的代码。如图 - 1 所示死锁模型展现了一个简单的 4 线程死锁场景。
2)线程统计查看
状态统计是对运行的线程依照运行状态进行的统计和汇总。用户在不齐全理解本人业务压力的状况下，对于可用线程数个别会配置一个十分富余的范畴，这样反而会因为过多的线程导致性能降落或者系统资源耗尽。如图 - 2 所示，能够发现超过 90% 的线程处于阻塞和期待状态，那么适当优化线程数量是能够缩小线程调度带来的开销以及不必要的资源节约。
如图 - 3 所示，处于运行阶段的线程数曾经超过 90%，进一步剖析可能存在线程泄露的问题。同时，运行的线程太多，线程切换的开销也是十分大的。
3)线程 CPU 使用率查看
对各 Java 线程 CPU 应用状况进行统计和排序，针对 CPU 使用率极高的线程线程栈进行剖析，能够疾速定位到程序热点。如图 - 4 所示，首个工作线程的 CPU 使用率达曾经到 100%，则开发人员可依据业务逻辑确定是否进行代码优化。
4)GC 线程数查看
GC 线程数往往是容易被用户漠视的指标。用户在设置并行 GC 线程数的时候容易漠视零碎的资源状况，或者随便将利用部署在 CPU 核数较多的物理机。如图 - 5 所示，咱们发现在一个 4 核 8GB 的容器中 G1 的并发收集线程数为 9（个别状况下并行 GC 的线程数是 GC 工作线程数的 1 /4），也就是在 GC 产生的时候可能会呈现 9 个并行的 GC 线程，这种状况下 CPU 资源会被短时间间接耗尽而零碎和业务阻塞。所以在应用 GC 收集器（如 CMS、G1）的时候尽可能设置或者关注 GC 的线程数。
诀窍二：GC 日志分析
日志剖析是对 Java 程序 GC 收集记录数据的剖析，而这部分数据的收集是须要开启特定选项的。所以，在启动 Java 程序前肯定要减少日志参数（如 JDK8：-Xloggc:logs/gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps；JDK11：-Xlog:gc*:logs/gc-%t.log:time,uptime）。GC 日志剖析的后果形容的是在过来一段时间内 Java 程序就内存回收的状态。通过剖析这些状态信息，用户能够十分不便的取得到 GC 参数甚至 Java 代码优化的指标数据。以下就 3 个剖析指标进行开展：
1)GC 的吞吐率
吞吐率形容的是在 JVM 运行时间段可用于业务解决的工夫占比，即非 GC 占用工夫。该值越大示意用户 GC 占用的工夫越少，JVM 性能越好。JVM 外部指定该值不能低于 90%，否则 JVM 自身所带来的性能损耗就会重大影响业务性能。如图 - 6 所示是 JDK8 的 CMS 运行 3 小时左右的日志剖析后果，剖析结果显示其吞吐率超过 99.2%，JVM（GC）导致的性能损耗是比拟低的。
2)暂停工夫统计
GC 暂停工夫指的是在 GC 过程中须要进行业务线程运行的工夫，该工夫须要在在一个正当的范畴内。如果绝大部分的暂停工夫超过预期（用户能够承受的范畴），则很有须要去调整 GC 参数以及堆大小，甚至设置并行 GC 线程数。如图 - 7 所示，95% 以上的 GC 暂停工夫是在 40ms 以内；而超过 100ms 的暂停可能是导致业务申请工夫毛刺的次要因素。为了打消暂停工夫稳定问题，能够抉择如 G1 GC 或 ZGC，或者调整并行线程数或者 GC 参数等。
3)GC 阶段散点图
散点图反映的是每一次 GC 操作开释的内存大小的散布状况。如图 - 8 所示，每次 GC 开释的内存大小基本一致，阐明内存开释过程比较稳定。但如果呈现比拟大的稳定或者呈现比拟多的 Full GC 则有可能是新生代区堆空间有余导致降职量较大；如果每次 GC 的开释量比拟少有可能是 G1 GC 自适应算法导致的新生代空间较小等等。因为散点图展现的数据无限，所以个别须要联合其它指标以及用户的 JVM 参数进行联结剖析。
诀窍三：JFR 事件分析
JFR 是 Java Flight Record 的缩写，是 JVM 内置的基于事件的 JDK 监控记录框架。社区中，JFR 优先于 OpenJDK11 上公布，后移植到 OpenJDK8 的较高版本 260 上，且沿用了对立的应用接口与操作命令 jcmd。同时，因为 JFR 录制个别对利用影响很小（默认开启的性能影响在 1% 以内），适宜长时间开启；且 JFR 能收集到如 Runtime、GC、线程栈、堆、IO 等在内的丰盛信息，十分不便用户理解 Java 程序的运行状况。
JFR 录制的事件有 100 多种，如果程序简单往往不到 10 分钟录制的 JFR 文件大小就会超过 500MB，所以用户在剖析时往往并不是所有的信息都会关注。以下就业务性能中常见几个做一下分享：
1)过程 CPU 占用率
CPU 采样默认距离是 1s，根本能及时反映以后过程的 CPU 均匀应用状况。在呈现 CPU 继续偏高，或者 CPU 呈现相似图 - 9 所示的 CPU 偶发飙高的状况时，都能够进行肯定的检测和剖析。通过进一步定位，此处 CPU 飙高与 GC 触发工夫统一，初步确认是 GC 导致的 CPU 变动。
2)GC 配置及暂停散布
GC 配置能够帮忙咱们理解到以后过程的 GC 收集器及其次要的配置参数，因为不必的收集器个性会不同，剖析堆空间、触发管制等参数也是十分重要的。控制参数能够帮忙咱们了解 GC 收集过程，比方图 -10 所示的 G1 收集器，设置的最大堆为 8GB，GC 暂停工夫在 40ms 左右（默认预期 200ms），是远低于预期值的。进一步剖析参数发现设置了 NewRatio 值为 2（对 G1 GC 不太熟悉的状况下，用户很容易设置该参数），导致新生代区的 GC 触发频繁，而且从数据看未触发混合 GC。为了减少对堆空间的利用，能够移除 NewRatio 参数，减少新生代区的最大值比例（因为未触发混合 GC，阐明堆回收时降职量非常低），升高回收块的回收门槛等，进而减少对整堆的应用。通过优化，堆空间的应用从原来的 4GB 进步到 7GB，YGC 频率从 20s/ 次进步到均匀 40s/ 次，GC 暂停工夫没有显著变动。
3)办法采样火焰图
办法火焰图是对调用办法采样次数的统计，比例越大示意调用次数越多。因为采样过程中有栈的残缺信息，对于用户来说是十分比拟直观的，性能优化的帮忙性大增。如图 -11 所示，能够很分明的看到 GroupHeap.match 执行次数比例靠近 30%，能够作为性能优化点。
4)IO 读写性能
查看 IO 性能多半是对程序处理性能呈现渐变的场景，比方降落或飙升。如从 socket 读入的数据量飙升，导致解决业务的 CPU 飙高；或者因为须要写出的数据变多，导致业务线程阻塞，解决能力降落等。如图 -11 所示，能够通过读取 / 写入趋势图判断在监控时间段的 IO 能力。
诀窍四：堆内容分析
堆内容分析是剖析 Java 堆 OOM（OutOfMemoryError）起因的罕用伎俩。OOM 次要有堆空间溢出、元空间溢出、栈空间溢出和间接内存溢出等，但并不是所有溢出状况都能够通过堆内容分析取得。对于堆转储的文件而言，内存溢出的可能性是不确定的，但能够通过一些定量的指标或者约定的条件作出判断，再通过开发或者测试人员进行最初的确认。以下分享三个有价值的掂量指标：
1)大对象查看
统计大对象散布信息能够帮忙咱们理解内存耗费在这部分对象上的比重，以及存在的大对象是否正当。过多的大对象无奈开释会更快的耗尽内存而呈现 OOM，相比全量的剖析所有对象而言，大对象的查看是具备代表性的，如图 -13 所示。
2)类加载查看
类加载统计次要统计的是程序以后加载的全副类信息，是计算元空间占用的重要数据。过多的加载类信息也会导致元空间被大量占用，在相似 RPC 场景下，缓存加载类信息是容易触发 OOM 的。
3)对象泄露查看
首先引入三个概念；
浅堆：一个对象所占用的内存大小，和对象的内容无关，只和对象的构造无关。
深堆：一个对象被 GC 回收后，能够实在开释的内存大小，即通过该对象拜访到的所有对象的浅堆之和（摆布树）。
摆布树：在对象的援用图中，所有指向对象 B 的门路都通过对象 A，则认为对象 A 摆布对象 B；如果对象 A 是离对象 B 最近的一个摆布对象，则认为对象 A 为对象 B 的间接支配者。
依照 GC 策略，堆中的对象只可能有两种状态，一种是通过 GC 的根可达的对象；另一种是通过 GC 根不可达的对象。不可达的对象会被 GC 收集器回收，对应的内存就会返回到零碎中去。而可达对象都是被用户间接或者间接援用的对象，所以对象泄露针对的就是被用户间接援用但永远不会被应用的对象，这些对象因为被援用而无奈开释。对象泄露不是相对的，而是绝对的，个别没有确切的规范，但能够通过对对象的深堆大小进行评估。比方检测到 HashMap 寄存了 4844 个对象（如图 -14 所示），计算 HashMap 浅堆约 115KB，看到这里可能感觉没有什么问题；但通过计算对象的深堆发现其超过 500MB。这种状况下，如果无奈开释 HashMap 而继续减少新的键值就有可能导致堆内存耗尽而呈现 OOM。
作者简介：
Nianwu，高级后端工程师
次要负责 Java 性能平台和 JDK 反对，对缺点检查和编译器也有深入研究。
获取更多精彩内容，请关注 [OPPO 互联网技术] 公众号