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

今天药忘吃喽~ 2023-02-25 07:10 9阅读 0赞

> 本文基于 OpenJDK 11

## 3. 虚拟机相关 Event ##

### 3.3. JIT即时编译相关 ###

JIT 即时编译可能会遇到编译后的代码缓存占满，或者因为空间有限或者代码设计问题，导致某些关键方法需要重编译导致性能问题，以及因为代码块过大导致编译失败从而性能有问题，这些问题我们可以通过 JFR 中相关的 Event 进行查询。  
**JFR 对于 Java 开发可以完全替换 JVM 编译日志**。

#### **额外讲解：JIT 相关的知识** ####

首先，这里简单介绍下 JIT 相关的知识（这里我推荐看 O’Rerilly 上面的 Java Performance 第二版的第四章：[Working with the JIT Compiler][]）：

**首先什么是 JIT：** 当 Java 被编译为字节码形式的 class 文件之后，他可以在任意的 JVM 运行。这里说的编译，主要是指**前端编译器**。但是 class 文件里面的字节码并不能直接运行，而是要通过**后端编译器**在程序运行期间，将字节码转变成机器码，这样电脑才能执行你的代码。

**Java Code Cache 是啥：** 如果 Java 每次都需要即时编译成机器码，再执行，效率太慢了。那么是不是对于某些热点代码，编译后的机器码，缓存起来，这样下次就不用重新即时编译了，多快乐。Java Code Cache 就是用来干这个的。但是编译后的机器码太大了，Java Code Cache 的空间是有限的，也不能将所有的代码都编译成机器码缓存起来。所以就需要一些优化与清理策略。

**C1，C2 编译器与分层编译（Tiered Compilation）以及编译级别（Compilation Level）：** C1，C2 按照老概念来看，分别是客户端编译器和服务端编译器，随着 -server 的 Java 参数的消失，代表着 Java 程序本质上不再区分客户端服务端，所以目前所有的 Java 进程都是 C1，C2混合使用。

C1 编译器对代码做一些简单的优化并加入一些采样代码， C2 针对 C1 加入的代码的采样结果，做更多的分析（语法解析，逃逸分析，高级优化器等等），优化成为更好的代码。C1是一个简单快速的编译器，主要关注点在于局部优化，而放弃许多耗时较长的全局优化手段。C2 则是关注于耗时较长的全局优化手段。同时由于 Java Code Cache 是有限的，有些代码可能优化后被淘汰，需要重新编译，没必要对于每种代码都进行 C1 C2 的优化，那些执行次数少的代码，直接编译执行即可。

C1，C2是怎么配合的呢？从 Java 7 开始引入了分层编译的概念，目前已经是默认的即时编译方式。Java 代码一共有如下几层编译级别：

*  level 0：代码直接解释执行
 *  level 1：通过 C1 编译器优化编译执行（不会加入采样代码，例如统计这段代码执行次数等等）
 *  level 2：通过 C1 编译器优化编译执行（加入非常轻量的采样代码）
 *  level 3：通过 C1 编译器优化编译执行（加入所有的采样代码）
 *  level 4：通过 C2 编译器优化编译执行（根据上一步采样代码的信息，决定如何优化）

一般情况下，热点代码都是经过 0 -> 3 -> 4 这个路径被优化的。但是也有例外情况：

*  **当方法过于简单的时候（例如只有一行代码）**，C2 不能在 C1 的基础上更加优化，则走向 level 1，去掉了采样代码。
 *  **如果 C2 线程正忙（C2 线程任务队列满了）**，则走向 level 2，因为认为 C2 一段时间内不会恢复，level 3 采集的很多数据有时效性，现在采集也没意义，所以先走向 level 2 减少采集。之后过一段时间，重新变成 level 3，等待 C2 闲时，走向 level 4
 *  **C1 忙，但是 C2 闲时**，直接从 level 0 升级到 level 4。

**Java Code Cache 分块（[Segmented Code Cache][]）：** 从 Java 9 开始引入的 Code Cache 分块，主要解决之前把所有种类代码放一起，导致扫描的时候效率低下。例如之前说的有些代码经过 C1 优化，之后 C2 优化，这些代码最好分开存储。（C1 优化过得代码，C2 优化完之后，C1的要被清理掉）。

目前 Java Code Cache 分为 3 块：

*  \*\*非方法代码堆（non-method code heap）：\*\*这些是 JIT 编译器要用到的内存区域，例如编译器要用的缓存等等。他们会永远存在于 Code Cache 内。
 *  \*\*带采样的代码堆（profiled code heap）：\*\*目前是经过 C1 编译器优化的代码，就是轻度优化，带采样代码的代码，存活时间比较短，因为 C1 优化的代码最终会被 C2 优化，或者退回 level 1 去掉采样。
 *  \*\*不带采样的代码堆（non-profiled code heap）：\*\*包含不带采样的代码，已经完全优化好，并且长期存活的代码。

默认情况下，非方法代码堆包括 3MB 的来自于虚拟机的固定空间占用，以及随着编译线程个数上涨而上涨的空间占用。剩下的空间，带采样的代码堆与不带采样的代码堆评分，可以通过如下参数修改：

*  \-XX:NonProfiledCodeHeapSize: 不带采样的代码堆大小.
 *  \-XX:ProfiledCodeHeapSize: 带采样的代码堆大小.
 *  \-XX:NonNMethodCodeHeapSize: 非方法代码堆大小.
 *  \-XX:ReservedCodeCacheSize 以上三个加起来需要等于这个

**Code Cache Sweeper（代码缓存清理器）：** 随着 Java Code Cache 的分块处理，目前 Code Cache Sweeper 只用扫描 带采样的代码堆 和 非方法代码堆，并且可以分开并发扫描，看那些代码缓存可以回收。

**Method Inline（方法内联）：** 通俗来讲，就是JVM在运行时优化编译好的代码，将**经常调用的方法从调用替换为方法体代码**，减少调用。通常发生在 C1 编译器优化。举一个简单的例子：在编写Java的POJO object时候，经常会用到getter和setter，这是从学校里学java开始，我们就一直使用的设计模式，为了保证POJO类对象的域安全。但是我们是否考虑过，如果每次都用这个而外的方法修改，那么是否都会多一次方法栈寻址调用？这样对性能肯定是有影响的。幸好我们有Java Inline Method这个机制，参考下面的代码：

public class JitInlining {
        public static void main(String args[]) {
            Position position = new Position(25);
            for (int i = 0; i < 1000000; ++i) {
                int x = position.getX();
                position.setX(x + 1);
            }
            System.out.println(position.getX());
        }
    }
    class Position {
        private int x;
        public Position(int x) {
            this.x = x;
        }
        public int getX() {
            return x;
        }
        public void setX(int x) {
            this.x = x;
        }
    }

加上jvm参数来看一下inline效果：`-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining`

@ 19   com.test.Position::getX (5 bytes)   accessor
    @ 27   com.test.Position::setX (6 bytes)   accessor

这个accessor代表jit识别这些方法是某个field的accessor（即getter或者setter），accessor是会被inline的。

**OSR（On Stack Replacement）：** 一种在运行时替换正在运行的函数/方法的栈帧的技术。JIT 优化，一般在某一段代码被执行很多次之后，例如：

for (int i = 0; i < 10000; i ++) {
        this.data++;
    }

`this.data++;`如果被编译器优化之后，这个循环还没执行完，则需要 OSR 机制，动态替换正在栈帧中待执行的代码。这样还没完成的循环，就可以用优化后的代码执行。

通常来看，应该把 **所有的栈上替换执行代码**都叫做 OSR，但是 Java 中**只针对于编译器优化的代码替换原有代码称为 OSR**，对于去优化的替换（就是用原有代码替换优化过的代码），称为**Bailout**

为什么会有这种**Bailout**的情况呢？代码优化可以分为（这里参考[大神的知乎回答][Link 1]）：

*  从低优化向高优化迁移：为了平衡启动性能（刚开始要启动速度快，所以要初始开销小的执行模式）和顶峰性能（代码执行一段时间，对于热点代码，想要更快需要更优化的执行模式，即便优化需要较大开销）
 *  从高优化向低优化迁移：有很多情况，这里仅举例：
    
     *  高优化层级做了很激进的优化：例如假设某个类不会有别的子类、某个引用一定不是null、某个引用所指向的对象一定是某个具体类型，等），而这个激进的假设假如失效了的话，就必须退回到没有做这些优化的“安全”的低优化层级去继续执行。这个非常重要，有了这种**Bailout**机制的支持，JIT编译器就可以对代码做非常激进的优化，性能受正确性要求的约束会得到放松，因而对常见代码模式可以生成更快的代码。
     *  高优化层级不便于**对代码做调试**，如果某个方法之前已经被JIT优化编译了，而后来有调试器动态决定调试该方法，则让它从高优化层级退回到便于调试的低优化层级（例如解释器或者无优化的JIT编译版本的代码）去执行。

#### **JIT即时编译相关的 Event 列表** ####

<table> 
 <thead> 
  <tr> 
   <th>事件名称</th> 
   <th>简介</th> 
   <th>default.jfc中的配置</th> 
   <th>profile.jfc中的配置</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>CompilerConfiguration</td> 
   <td>即时编译器配置采集</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
  </tr> 
  <tr> 
   <td>CompilerStatistics</td> 
   <td>即时编译器统计数据采集</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 1000ms一次</td> 
  </tr> 
  <tr> 
   <td>Compilation</td> 
   <td>JIT编译事件收集，编译时间大于某一时间限制则被收集</td> 
   <td><strong>是否启用：</strong> 是；<strong>时间阈值：</strong> 1s</td> 
   <td><strong>是否启用：</strong> 是；<strong>时间阈值：</strong> 100ms</td> 
  </tr> 
  <tr> 
   <td>CompilierPhase</td> 
   <td>编译阶段，较为底层的事件，一般 Java 开发不关心这个时间</td> 
   <td><strong>是否启用：</strong> 是；<strong>时间阈值：</strong> 60s</td> 
   <td><strong>是否启用：</strong> 是；<strong>时间阈值：</strong> 10s</td> 
  </tr> 
  <tr> 
   <td>CompilationFailure</td> 
   <td>编译失败事件，default没有开启，可以考虑开启，但是里面的信息都比较底层，所以一般只看 Compilation 事件定位问题</td> 
   <td><strong>是否启用：</strong> 否</td> 
   <td><strong>是否启用：</strong> 是</td> 
  </tr> 
  <tr> 
   <td>CompilerInlining</td> 
   <td>编译内联事件，这个事件线上不要开启，很影响性能，测试阶段可以开启看看内联失败的原因</td> 
   <td><strong>是否启用：</strong> 否</td> 
   <td><strong>是否启用：</strong> 否</td> 
  </tr> 
  <tr> 
   <td>CodeCacheConfiguration</td> 
   <td>代码缓存配置采集</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
  </tr> 
  <tr> 
   <td>CodeCacheStatistics</td> 
   <td>代码缓存统计数据采集</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每一个 chunk 采集一次</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每一个 chunk 采集一次</td> 
  </tr> 
  <tr> 
   <td>CodeCacheFull</td> 
   <td>代码缓存空间已满事件</td> 
   <td><strong>是否启用：</strong> 是</td> 
   <td><strong>是否启用：</strong> 是</td> 
  </tr> 
  <tr> 
   <td>CodeSweeperConfiguration</td> 
   <td>代码缓存清理配置采集</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每写入一个新的 chunk 的开头采集一次</td> 
  </tr> 
  <tr> 
   <td>CodeSweeperStatistics</td> 
   <td>代码缓存清理统计数据采集，这个我们一般不看的</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每一个 chunk 采集一次</td> 
   <td><strong>是否启用：</strong> 是；<strong>周期：</strong> 每一个 chunk 采集一次</td> 
  </tr> 
  <tr> 
   <td>SweepCodeCache</td> 
   <td>代码缓存清理事件采集</td> 
   <td><strong>是否启用：</strong> 是；<strong>时间阈值：</strong> 100ms</td> 
   <td><strong>是否启用：</strong> 是；<strong>时间阈值：</strong> 100ms</td> 
  </tr> 
 </tbody> 
</table>

**CompilerConfiguration 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Thread Count</td> 
   <td>线程个数</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>Tiered Compilation</td> 
   <td>是否启用了分层编译（Tiered Compilation）</td> 
   <td>true</td> 
  </tr> 
 </tbody> 
</table>

**CompilerStatistics 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Bailouts</td> 
   <td>放弃编译好的机器码使用原有字节码执行的总次数（去优化，对应上面提到的 OSR 中的 Bailout 情况），这个如果经常发生，则需要看一下发生的事件对应的其他 Compiler 相关的事件是否能定位到对应的方法</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>Compiled Methods</td> 
   <td>编译的方法总数</td> 
   <td>41329</td> 
  </tr> 
  <tr> 
   <td>Invalidated Compilations</td> 
   <td>无效的编译</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>Compilation Resulting Code Size</td> 
   <td>程序启动以来编译后的代码大小</td> 
   <td>85502368 B</td> 
  </tr> 
  <tr> 
   <td>Compilation Resulting Size</td> 
   <td>程序启动以来编译占用的总大小</td> 
   <td>128496488 B</td> 
  </tr> 
  <tr> 
   <td>OSR Bytes Compiled</td> 
   <td>On Stack Replacement(栈上替换，这里是向上优化) 编译的代码字节大小，这个一般为采集不到，我们也不从这里看大小，一般为0，不用关注</td> 
   <td>0 B</td> 
  </tr> 
  <tr> 
   <td>OSR Compilations</td> 
   <td>程序启动以来 On Stack Replacement(栈上替换，这里是向上优化) 编译总次数</td> 
   <td>609</td> 
  </tr> 
  <tr> 
   <td>Peak Time</td> 
   <td>程序启动以来最长编译时间</td> 
   <td>961 ms</td> 
  </tr> 
  <tr> 
   <td>Standard Bytes Compiled</td> 
   <td>标准编译代码大小，这个一般为采集不到，我们也不从这里看大小，一般为0，不用关注</td> 
   <td>0 B</td> 
  </tr> 
  <tr> 
   <td>Standard Compilations</td> 
   <td>程序启动以来标准编译次数</td> 
   <td>40108</td> 
  </tr> 
  <tr> 
   <td>Total time</td> 
   <td>JIT 编译总占用时间</td> 
   <td>206547 ms</td> 
  </tr> 
 </tbody> 
</table>

**Compilation 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>持续时间</td> 
   <td>事件持续时间</td> 
   <td>55607927 ticks</td> 
  </tr> 
  <tr> 
   <td>结束时间</td> 
   <td>事件结束时间</td> 
   <td>2869587482704980480 epochticks</td> 
  </tr> 
  <tr> 
   <td>Event Thread</td> 
   <td>编译线程，可能是 C1 CompilerThreadN 或者是 C2 CompilerThreadN，分别对应 C1，C2线程</td> 
   <td>C1 CompilerThread0</td> 
  </tr> 
  <tr> 
   <td>Compiled Code Size</td> 
   <td>编译后的代码大小</td> 
   <td>11048 B</td> 
  </tr> 
  <tr> 
   <td>Compilation Identifier</td> 
   <td>本次编译对应的全局唯一id，通过这个 id 确认哪些事件对应的是同一次编译。</td> 
   <td>5224</td> 
  </tr> 
  <tr> 
   <td>Compilation Level</td> 
   <td>编译级别 1，2，3，4 （0不会出现的，因为就是没编译）</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>Inlined Code Size</td> 
   <td>内联代码大小</td> 
   <td>1328 B</td> 
  </tr> 
  <tr> 
   <td>On Stack Replacement</td> 
   <td>是否为栈上替换</td> 
   <td>false</td> 
  </tr> 
  <tr> 
   <td>Java Method</td> 
   <td>对应的 Java 方法</td> 
   <td>String java.io.WinNTFileSystem.resolve(File)</td> 
  </tr> 
  <tr> 
   <td>Java Method Succeeded</td> 
   <td>是否编译成功，如果没有成功，看看是否代码块太大导致的</td> 
   <td>true</td> 
  </tr> 
 </tbody> 
</table>

**CompilierPhase** 事件我们并不关心，也不会打开，跳过。**CompilationInlining** 我们也是一般不看并且不会打开，这里也跳过。

**CompilerFailure 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Event Thread</td> 
   <td>编译线程，可能是 C1 CompilerThreadN 或者是 C2 CompilerThreadN，分别对应 C1，C2线程</td> 
   <td>C1 CompilerThread0</td> 
  </tr> 
  <tr> 
   <td>Compilation Identifier</td> 
   <td>本次编译对应的全局唯一id，通过这个 id 确认哪些事件对应的是同一次编译。</td> 
   <td>6012</td> 
  </tr> 
  <tr> 
   <td>Failure Message</td> 
   <td>失败信息</td> 
   <td>Jvmti state change invalidated dependencies（JVM正在关闭会报这个）</td> 
  </tr> 
 </tbody> 
</table>

**CodeCacheConfiguration 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Expansion size</td> 
   <td>每次扩展大小</td> 
   <td>65536 B</td> 
  </tr> 
  <tr> 
   <td>Initial Size</td> 
   <td>初始大小</td> 
   <td>2555904 B</td> 
  </tr> 
  <tr> 
   <td>Minimum Block Length</td> 
   <td>内存分配最小块大小</td> 
   <td>4 B</td> 
  </tr> 
  <tr> 
   <td>Non-nmethod Size</td> 
   <td>对应上面说的 非方法代码堆大小</td> 
   <td>5825164 B</td> 
  </tr> 
  <tr> 
   <td>Non-profiled Size</td> 
   <td>对应上面说的 不带采集代码堆大小</td> 
   <td>122916538 B</td> 
  </tr> 
  <tr> 
   <td>Profiled Size</td> 
   <td>对应上面说的 带采集代码堆大小</td> 
   <td>122916538 B</td> 
  </tr> 
  <tr> 
   <td>Reserved Size</td> 
   <td>总大小</td> 
   <td>251658240 B</td> 
  </tr> 
  <tr> 
   <td>Reserved Top</td> 
   <td>代码缓存内存堆地址</td> 
   <td>140692249706496</td> 
  </tr> 
  <tr> 
   <td>Start Address</td> 
   <td>代码缓存内存堆基地址</td> 
   <td>140691998048256</td> 
  </tr> 
 </tbody> 
</table>

**CodeCacheFull 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Event Thread</td> 
   <td>编译线程，可能是 C1 CompilerThreadN 或者是 C2 CompilerThreadN，分别对应 C1，C2线程</td> 
   <td>C1 CompilerThread0</td> 
  </tr> 
  <tr> 
   <td>Adaptors</td> 
   <td>非方法堆里面元素数量</td> 
   <td>578</td> 
  </tr> 
  <tr> 
   <td>Code Heap</td> 
   <td>事件指的是哪个代码堆，看 CacheCache目前处于什么阶段，如果是运行阶段，则可能是：CodeHeap ‘non-profiled nmethods’，CodeHeap ‘profiled nmethods’，CodeHeap ‘non-nmethods’，如果程序刚启动，JVM原生的占用non-nmethod就满了），可能就是 Unused，如果还没拆分出来，则是笼统的 CodeCache</td> 
   <td>Unused</td> 
  </tr> 
  <tr> 
   <td>Commited Top</td> 
   <td>代码缓存内存堆目前请求提交地址</td> 
   <td>140692249706496</td> 
  </tr> 
  <tr> 
   <td>Entries</td> 
   <td>元素个数</td> 
   <td>91512</td> 
  </tr> 
  <tr> 
   <td>Full Count</td> 
   <td>目前为止，CodeCacheFull次数</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>Methods</td> 
   <td>编译方法数量</td> 
   <td>854</td> 
  </tr> 
  <tr> 
   <td>Reserved Top</td> 
   <td>代码缓存内存堆地址</td> 
   <td>140692249706496</td> 
  </tr> 
  <tr> 
   <td>Start Address</td> 
   <td>代码缓存内存堆开始地址</td> 
   <td>140692249706496</td> 
  </tr> 
  <tr> 
   <td>Unallocated</td> 
   <td>未分配内存大小</td> 
   <td>2637824 B</td> 
  </tr> 
 </tbody> 
</table>

**CodeCacheStatistics 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Adaptors</td> 
   <td>非方法堆里面元素数量</td> 
   <td>578</td> 
  </tr> 
  <tr> 
   <td>Code Heap</td> 
   <td>事件指的是哪个代码堆，看 CacheCache目前处于什么阶段，如果是运行阶段，则可能是：CodeHeap ‘non-profiled nmethods’，CodeHeap ‘profiled nmethods’，CodeHeap ‘non-nmethods’，如果程序刚启动，JVM原生的占用non-nmethod就满了），可能就是 Unused，如果还没拆分出来，则是笼统的 CodeCache</td> 
   <td>Unused</td> 
  </tr> 
  <tr> 
   <td>Entries</td> 
   <td>元素个数</td> 
   <td>91512</td> 
  </tr> 
  <tr> 
   <td>Full Count</td> 
   <td>目前为止，CodeCacheFull次数</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>Methods</td> 
   <td>编译方法数量</td> 
   <td>854</td> 
  </tr> 
  <tr> 
   <td>Reserved Top</td> 
   <td>代码缓存内存堆地址</td> 
   <td>140692249706496</td> 
  </tr> 
  <tr> 
   <td>Start Address</td> 
   <td>代码缓存内存堆开始地址</td> 
   <td>140692249706496</td> 
  </tr> 
  <tr> 
   <td>Unallocated</td> 
   <td>未分配内存大小</td> 
   <td>2637824 B</td> 
  </tr> 
 </tbody> 
</table>

**CodeSweeperConfiguration 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>Code Cache Flushing Enabled</td> 
   <td>是否启用了Code Cache Flushing，默认也都是启用的</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>Code Sweeper Enabled</td> 
   <td>是否启用了CodeSweeper，默认都是启用的</td> 
   <td>true</td> 
  </tr> 
 </tbody> 
</table>

**CodeSweeperStatistics** 我们不关心

**SweepCodeCache 事件结构**

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
   <th>举例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开始时间</td> 
   <td>事件开始时间</td> 
   <td>1594215268138540326 epochns</td> 
  </tr> 
  <tr> 
   <td>持续时间</td> 
   <td>事件持续时间</td> 
   <td>55607927 ticks</td> 
  </tr> 
  <tr> 
   <td>结束时间</td> 
   <td>事件结束时间</td> 
   <td>2869587482704980480 epochticks</td> 
  </tr> 
  <tr> 
   <td>Event Thread</td> 
   <td>清理线程</td> 
   <td>Sweeper thread</td> 
  </tr> 
  <tr> 
   <td>Methods Flushed</td> 
   <td>现在为止刷新的方法数量</td> 
   <td>5</td> 
  </tr> 
  <tr> 
   <td>Sweep Identifier</td> 
   <td>全局唯一清理ID</td> 
   <td>737</td> 
  </tr> 
  <tr> 
   <td>Methods Swept</td> 
   <td>现在为止清理的方法数量</td> 
   <td>26700</td> 
  </tr> 
  <tr> 
   <td>Methods Zombified</td> 
   <td>现在为止僵尸化的方法数量</td> 
   <td>2</td> 
  </tr> 
 </tbody> 
</table>

[Working with the JIT Compiler]: https://www.oreilly.com/library/view/java-performance-2nd/9781492056102/ch04.html
[Segmented Code Cache]: https://openjdk.java.net/jeps/197
[Link 1]: https://www.zhihu.com/question/45910849/answer/100636125