JVM CodeHeap中C2编译代码因CodeCacheFlush导致性能回退？CompileThresholdScaling与TieredStopAtLevel调优 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

JVM CodeHeap 中 C2 编译代码因 CodeCacheFlush 导致性能回退？CompileThresholdScaling 与 TieredStopAtLevel 调优

大家好，今天我们来深入探讨一个 JVM 性能调优中常见但又容易被忽视的问题：C2 编译代码因 CodeCacheFlush 导致的性能回退，以及如何通过 CompileThresholdScaling 和 TieredStopAtLevel 这两个参数进行调优。

CodeCache 的作用与 CodeCacheFlush 的产生

首先，我们需要了解 CodeCache 在 JVM 中的作用。CodeCache 是 JVM 专门用于存储 JIT (Just-In-Time) 编译器编译后的本地代码的区域。HotSpot JVM 中，JIT 编译器主要有两个：C1 编译器 (Client Compiler) 和 C2 编译器 (Server Compiler)。C1 编译器主要进行简单的优化，编译速度快，但优化程度较低；C2 编译器则进行更激进的优化，编译速度较慢，但优化后的代码性能更高。

当 JVM 运行一段时间后，频繁执行的热点代码会被 JIT 编译器编译成机器码并存储到 CodeCache 中，从而显著提升程序的执行效率。

然而，CodeCache 的空间是有限的。当 CodeCache 使用率达到一定阈值时，JVM 会触发 CodeCacheFlush 操作，即清理 CodeCache 中的部分或全部已编译代码。CodeCacheFlush 的触发原因主要有以下几种：

CodeCache 已满: 这是最常见的原因。当 CodeCache 使用率达到 ReservedCodeCacheSize 的上限时，JVM 会尝试清理 CodeCache 来释放空间。
低内存: 在内存紧张的情况下，JVM 为了保证整体的稳定性，可能会主动清理 CodeCache 来释放内存。
安全点 (Safepoint) 操作: 在某些安全点操作中，JVM 可能会强制进行 CodeCacheFlush。
显式调用: 某些工具或 API 可能会显式地触发 CodeCacheFlush。

CodeCacheFlush 会导致严重的性能回退，因为它会将已经编译好的代码丢弃，下次再执行到这些代码时，需要重新解释执行或者重新编译。尤其对于 C2 编译的代码，重新编译的代价非常高昂，会导致明显的性能抖动。

如何判断 CodeCacheFlush 是否是性能瓶颈？

要判断 CodeCacheFlush 是否是导致性能回退的原因，我们需要收集 JVM 的相关监控数据。以下是一些常用的方法：

GC 日志: 通过配置 GC 日志，我们可以查看 CodeCache 相关的事件，例如 CodeCache is full，CodeCache flushing 等。
```
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintCodeCache
```
分析 GC 日志，我们可以看到 CodeCache 的使用情况以及 CodeCacheFlush 的发生频率。
JMX: 通过 JMX，我们可以实时监控 CodeCache 的使用情况。可以使用 JConsole，VisualVM 等工具连接到 JVM，查看 java.lang:type=MemoryPool,name=Code Cache 的相关属性，例如 Usage.Used，Usage.Max 等。
Java Flight Recorder (JFR): JFR 是 Oracle JDK 自带的性能分析工具，可以记录 JVM 运行时的详细信息，包括 CodeCache 相关的事件。
```
jcmd <pid> JFR.start duration=60s filename=myrecording.jfr
```
使用 JFR 分析工具，例如 Java Mission Control (JMC)，可以清晰地看到 CodeCache 的使用情况和 CodeCacheFlush 事件的发生时间。

通过以上方法，我们可以收集到 CodeCache 的使用情况和 CodeCacheFlush 的发生频率。如果发现 CodeCache 使用率很高，并且频繁发生 CodeCacheFlush，那么很可能 CodeCacheFlush 是导致性能回退的原因。

`CompileThresholdScaling` 与 `TieredStopAtLevel` 的作用

在了解了 CodeCacheFlush 的危害后，我们需要寻找合适的解决方案。CompileThresholdScaling 和 TieredStopAtLevel 是两个常用的 JVM 参数，可以用来控制 JIT 编译的行为，从而缓解 CodeCacheFlush 的问题。

`CompileThresholdScaling`

CompileThresholdScaling 参数用于调整方法被编译的阈值。在分层编译 (Tiered Compilation) 模式下，方法首先会被 C1 编译器编译，当方法的调用次数超过一定的阈值后，才会被 C2 编译器重新编译。CompileThresholdScaling 的作用是调整这个阈值。

值越大，阈值越高: 方法更不容易被编译，从而减少 CodeCache 的使用。
值越小，阈值越低: 方法更容易被编译，可能导致 CodeCache 更快地被填满。

CompileThresholdScaling 的默认值为 1.0。通常情况下，我们可以尝试将其调整到 2.0 或 3.0，以降低编译的频率，从而减少 CodeCache 的使用。

`TieredStopAtLevel`

TieredStopAtLevel 参数用于控制分层编译的级别。分层编译模式下，方法的编译过程分为几个级别：

0: 解释执行。
1: C1 编译，无 Profiling。
2: C1 编译，Limited Profiling。
3: C1 编译，Full Profiling。
4: C2 编译。

TieredStopAtLevel 的作用是指定编译的最高级别。例如，如果将其设置为 1，那么方法最多只会被 C1 编译器编译，而不会被 C2 编译器编译。

值越小，编译级别越低: 减少 C2 编译的使用，从而减少 CodeCache 的使用。
值越大，编译级别越高: 允许 C2 编译的使用，可以获得更好的性能，但也可能导致 CodeCache 更快地被填满。

TieredStopAtLevel 的默认值为 4，即允许使用 C2 编译。通常情况下，我们可以尝试将其调整到 3 或更低，以禁用 C2 编译，从而减少 CodeCache 的使用。

调优策略与实践

在实际应用中，我们需要根据具体的场景和性能指标，选择合适的调优策略。以下是一些常用的策略：

增加 ReservedCodeCacheSize: 这是最直接的解决方案。增加 CodeCache 的大小，可以减少 CodeCacheFlush 的发生频率。但是，增加 CodeCache 的大小也会占用更多的内存。
```
-XX:ReservedCodeCacheSize=512m
```
调整 CompileThresholdScaling: 如果 CodeCacheFlush 的原因是方法编译过于频繁，可以尝试增加 CompileThresholdScaling 的值。
```
-XX:CompileThresholdScaling=2.0
```
调整 TieredStopAtLevel: 如果对性能要求不高，可以尝试降低 TieredStopAtLevel 的值，禁用 C2 编译。
```
-XX:TieredStopAtLevel=3
```
禁用分层编译: 如果对性能要求不高，并且 CodeCacheFlush 问题非常严重，可以完全禁用分层编译。
```
-XX:-TieredCompilation
```
优化代码: 优化代码，减少热点方法的数量，也可以降低 CodeCache 的使用。

在进行调优时，我们需要进行充分的测试，评估不同参数组合对性能的影响。可以使用性能测试工具，例如 JMeter，来模拟真实的用户场景，并收集 JVM 的监控数据，例如吞吐量，响应时间，CPU 使用率等。

以下是一个简单的调优示例：

假设我们有一个 Web 应用，运行在 Tomcat 上。通过监控发现，CodeCache 使用率很高，并且频繁发生 CodeCacheFlush，导致响应时间不稳定。

首先，我们可以尝试增加 ReservedCodeCacheSize 的值：

-XX:ReservedCodeCacheSize=512m

进行性能测试后，发现 CodeCacheFlush 的频率有所降低，但仍然存在。

接下来，我们可以尝试调整 CompileThresholdScaling 的值：

-XX:CompileThresholdScaling=2.0

再次进行性能测试后，发现 CodeCacheFlush 的频率进一步降低，响应时间也更加稳定。

如果仍然存在 CodeCacheFlush 问题，我们可以尝试降低 TieredStopAtLevel 的值：

-XX:TieredStopAtLevel=3

进行性能测试后，发现 CodeCacheFlush 的频率大幅降低，但吞吐量也有所下降。

最终，我们需要根据具体的性能指标，选择合适的参数组合。在这个例子中，我们可能需要在响应时间和吞吐量之间进行权衡，选择一个能够满足需求的参数组合。

代码示例

以下是一些简单的代码示例，用于演示如何监控 CodeCache 的使用情况：

使用 JMX:

import javax.management.*;
import javax.management.remote.*;
import java.io.IOException;
import java.lang.management.ManagementFactory;
import java.rmi.server.RMIClientSocketFactory;
import java.rmi.server.RMIServerSocketFactory;
import java.util.HashMap;
import java.util.Map;

public class CodeCacheMonitor {

    public static void main(String[] args) throws Exception {
        // 获取 MBeanServer
        MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();

        // 构建 MemoryPool 的 ObjectName
        ObjectName objectName = new ObjectName("java.lang:type=MemoryPool,name=Code Cache");

        // 获取 CodeCache 的 Usage 信息
        while (true) {
            MemoryUsage usage = MemoryUsage.from(mbs.getAttributes(objectName, new String[]{"Usage"}).get(0).getValue());
            long used = usage.getUsed();
            long max = usage.getMax();

            System.out.println("CodeCache Used: " + used / 1024 / 1024 + " MB, Max: " + max / 1024 / 1024 + " MB");

            Thread.sleep(1000);
        }
    }
}

这个示例代码通过 JMX 连接到 JVM，获取 CodeCache 的使用情况，并打印到控制台。

使用 Runtime API:

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryPoolMXBean;
import java.lang.management.MemoryUsage;
import java.util.List;

public class CodeCacheMonitorRuntime {

    public static void main(String[] args) throws InterruptedException {
        // 获取 MemoryPoolMXBean 列表
        List<MemoryPoolMXBean> memoryPoolMXBeans = ManagementFactory.getMemoryPoolMXBeans();

        // 查找 CodeCache 的 MemoryPoolMXBean
        MemoryPoolMXBean codeCachePool = null;
        for (MemoryPoolMXBean pool : memoryPoolMXBeans) {
            if (pool.getName().equals("Code Cache")) {
                codeCachePool = pool;
                break;
            }
        }

        if (codeCachePool == null) {
            System.out.println("CodeCache MemoryPool not found.");
            return;
        }

        // 获取 CodeCache 的 Usage 信息
        while (true) {
            MemoryUsage usage = codeCachePool.getUsage();
            long used = usage.getUsed();
            long max = usage.getMax();

            System.out.println("CodeCache Used: " + used / 1024 / 1024 + " MB, Max: " + max / 1024 / 1024 + " MB");

            Thread.sleep(1000);
        }
    }
}

这个示例代码通过 Runtime API 获取 CodeCache 的使用情况，并打印到控制台。

注意事项

在进行 CodeCache 调优时，需要注意以下几点：

监控是关键: 在进行任何调优之前，都需要收集 JVM 的监控数据，了解 CodeCache 的使用情况和 CodeCacheFlush 的发生频率。
逐步调整: 不要一次性调整太多的参数，应该逐步调整，并进行充分的测试，评估每个参数对性能的影响。
场景依赖: 不同的应用场景，需要不同的调优策略。需要根据具体的场景和性能指标，选择合适的参数组合。
长期观察: CodeCache 的使用情况可能会随着应用的运行而变化，需要长期观察，并根据实际情况进行调整。

CodeCache 调优，关键在于平衡

总而言之，CompileThresholdScaling 和 TieredStopAtLevel 是两个有用的 JVM 参数，可以用来缓解 CodeCacheFlush 的问题。但是，它们也会影响程序的性能。在实际应用中，我们需要根据具体的场景和性能指标，选择合适的调优策略。关键在于找到性能和 CodeCache 使用之间的平衡点。