深度探索JFR - JFR详细介绍与生产问题定位落地 - 3. 各种Event详细说明与JVM调优策略（2）

2. JAVA 应用相关

2.4. Java Monitor 同步锁相关

主要是三种 Event：

当进入同步块，尝试获取锁的时候，产生 JavaMonitorEnter Event；当调用 Object.wait() 进入等待时，会产生 JavaMonitorWait Event；当 锁升级（另一种说法是锁膨胀）时，产生 JavaMonitorWait Event。

下面我从网上看到的这张图，有助于理解这三种事件：

• JavaMonitorEnter（Java Monitor Blocked）：进入 Java Monitor Event。当需要进入同步代码时（字节码 monitorenter），会产生这个 Event。在 default.jfc 中默认为启用的，并且会追踪堆栈，阈值是 20ms；采集的信息包括：开始时间，持续时间，结束时间，线程，Monitor Address，Monitor Class，之前持有这个 Monitor 的线程。
• JavaMonitorInflated（Java Monitor Inflated）：发生锁升级的时候的 Event。在 default.jfc 中默认为启用的，并且会追踪堆栈，阈值是 20ms；采集的信息包括：开始时间，持续时间，结束时间，线程，Monitor Address，Monitor Class，锁升级原因
• JavaMonitorWait（Java Monitor Wait）：调用 Object.wait() 进入等待时，会产生 JavaMonitorWait Event；在 default.jfc 中默认为启用的，并且会追踪堆栈，阈值是 20ms；采集的信息包括：开始时间，持续时间，结束时间，线程，Monitor Address，Monitor Class，唤醒线程Thread， 是否超时， 超时时间。

一般的在默认情况下， JavaMonitorEnter 和 JavaMonitorWait 采集到的在阈值以上的会比较多，一般不会有 JavaMonitorInflated 事件，除非发生 CPU 资源耗尽或者程序不断 dump 导致一直处于 safepoint。

但是并不是所有的 JavaMonitorEnter 和 JavaMonitorWait Event 都是我们关心的，如何快速找到我们关心的关键 Event 呢？

先举一个 JavaMonitorEnter 的例子： 从事件浏览器视角去看， Event 太多了，我们建一个 JavaMonitorEnter Event 的视图：

一般的，我会按照 Monitor class 去分类看，争用同一个对象锁一般是同一个业务：

我们来看第一个计数最多的，点击这个分类，在下面的列表按照持续需时间倒序，查看线程以及堆栈：

发现是因为本地缓存更新，导致比较慢，这里本地缓存是读取的数据库，读取的数据比较多，400ms 的比较正常。

我们再来看另一个，Monitor class 为 java.lang.Object 的：

从堆栈上看出是获取 Lettuce 连接时候，锁等待了320ms。查看源代码，发现是连接初始化，导致比较慢，初始化好连接之后没再出现了。

这里建议，针对微服务应用，再调高阈值到 50ms。

2.5. Java Thread 相关

四个事件：

• ThreadStart：线程开始， Thread.start() 时，就会产生这个 Event 记录
• ThreadEnd：线程结束，就会产生这个 Event 记录
• ThreadPark：一般在 await/notify 的 await 的时候，调用 Unsafe.park() 就会产生这个 Event 记录
• ThreadSleep：线程休眠， Thread.sleep()时，就会产生这个 Event 记录

这些事件我们一般都不关心，Java 线程阻塞与热点方法和 CPU 消耗等，有其他的 Event，在 default.jfc 中这四个 Event 默认都是采集的，这里建议关闭这四个 Event 的采集

2.6. 网络IO socket 相关

• SocketRead: 网络读，在 default.jfc 中，默认启用，并且会追踪堆栈，阈值是 20ms；采集的信息包括：开始时间，持续时间，结束时间，线程，远程 IP，读取字节大小，是否是流读取的末尾，远程 Host，远程 Port，超时时间
• SocketWrite: 网络写，在 default.jfc 中，默认启用，并且会追踪堆栈，阈值是 20ms；采集的信息包括：开始时间，持续时间，结束时间，线程，远程 IP，写入字节大小，远程 Host，远程 Port

堆栈采集对于这种 Event 很重要，但是对于 Spring Cloud 这样的框架，调用层次极为复杂，可能默认采集堆栈深度（64）不够，需要增大才能看到自己的业务代码堆栈。但是要注意的一点是：堆栈采集深度，对于性能影响很大，以最坏的情况考虑，可以理解为增加多少倍的堆栈深度，对性能的影响就提高多少倍。 建议对于常态化的线上监控，堆栈深度最多不超过 128.

2.7. 一些统计数据相关

• ClassLoaderStatistics: 类加载器相关统计数据，default.jfc 中默认打开，每个 DataChunk 采集一次，一般不会去关心类加载器的统计数据，建议关闭。
• ClassLoadingStatistics: 类加载相关统计数据，default.jfc 中默认打开，每秒采集一次，一般不会去关心类加载的统计数据，建议关闭。
• ExceptionStatistics：异常统计数据，default.jfc 中默认打开，每秒采集一次，一般异常通过日志处理，也不太会关心这个统计数据，建议关闭
• JavaThreadStatistics：Java 线程数量统计数据，default.jfc 中默认打开，每秒采集一次线程数量，这个还有些参考意义，建议保留默认配置。采集的数据包括：到目前为止累计线程数量（包括已经 stop 的），当前活动线程数量，守护线程数量，采集时间内峰值线程数量。个人感觉不用每秒采集一次，改成每分钟即可。
• ThreadAllocationStatistics：线程分配内存大小统计，包括了线程从开始到现在一共分配的内存大小（包括已释放的），default.jfc 中默认打开，每个 DataChunk 采集一次，参考意义不大，建议关闭

3. 虚拟机相关 Event

3.1. JVM 启动参数 Flag 相关

JVM 启动参数包含很多配置， 同时也可以通过 JVMTI，jcmd 命令等等动态修改这些配置， 如果我们想看这些配置以及修改的时间点，那么可以打开这些 Event 的采集：

• BooleanFlag 与 BooleanFlagChange ：布尔状态位以及变化。对应的就是通过类似于通过+``-配置的哪些状态位，例如-XX:+UseCompressedOops就是打开压缩对象指针
• DoubleFlag 与 DoubleFlagChange：double状态位，例如-XX:InitialRAMPercentage=52.0配置初始内存堆栈占用比例（只有在没指定-Xmx和-Xms的时候有效）
• IntFlag 与 IntFlagChange
• UnsignedIntFlag 与 UnsignedIntFlagChange
• LongFlag 与 LongFlagChange
• UnsignedLongFlag 与 UnsignedLongFlagChange
• StringFlag 与 StringFlagChanged

这个对性能影响是很小的，所以在系统自带的 default.jfc 中就打开了。我这里建议还是打开，毕竟基本所有状态位是可以通过 jcmd 命令修改的，如果有对比需求，对比修改前还有修改后性能影响，那么状态位变换时间就很重要了

3.2. 类加载相关

主要包括三种 Event：

• Class Define： 类定义
• Class Load： 类加载
• Class Unload： 类卸载

这些事件我们平常开发一般不会去关心，一般之后开发框架或者定位框架问题的时候，才会去关心类加载器相关的问题。而且这个用阿里开源的工具 Arthas 更加好用(https://alibaba.github.io/arthas/sc.html)：

$ sc -d demo.MathGame
class-info        demo.MathGame
code-source       /private/tmp/arthas-demo.jar
name              demo.MathGame
isInterface       false
isAnnotation      false
isEnum            false
isAnonymousClass  false
isArray           false
isLocalClass      false
isMemberClass     false
isPrimitive       false
isSynthetic       false
simple-name       MathGame
modifier          public
annotation
interfaces
super-class       +-java.lang.Object
class-loader      +-sun.misc.Launcher$AppClassLoader@3d4eac69
                    +-sun.misc.Launcher$ExtClassLoader@66350f69
classLoaderHash   3d4eac69
 
Affect(row-cnt:1) cost in 875 ms.