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.
