CodeCache满导致编译停止？-XX:+UseCodeCacheFlushing与分层编译阈值调整

CodeCache 满了？别慌，我们来聊聊解决之道

大家好！今天我们来聊一个在 JVM 性能调优中经常遇到的问题：CodeCache 满了导致编译停止。这个问题对于一些运行时间较长、代码量较大的应用来说尤为突出。我们会深入探讨这个问题的原因、影响以及应对策略，重点关注 -XX:+UseCodeCacheFlushing 和分层编译阈值调整这两个关键的优化方向。

1. CodeCache 究竟是什么？

首先，我们要明确 CodeCache 的概念。CodeCache 是 JVM 专门用于存储 JIT (Just-In-Time) 编译器编译后的本地机器码的区域。简单来说，当 JVM 发现某个方法被频繁调用（满足一定的“热点”条件）时，JIT 编译器会将该方法的字节码编译成本地机器码，并将编译后的代码存储在 CodeCache 中。这样，下次再调用该方法时，JVM 就可以直接执行本地机器码，而无需再次解释执行字节码，从而显著提高程序的运行效率。

CodeCache 位于 JVM 的 Metaspace (元空间) 区域，但它与 Metaspace 中存储的类元数据是分开管理的。CodeCache 的大小是固定的，可以通过 -XX:ReservedCodeCacheSize 参数进行设置。

2. CodeCache 满了会发生什么？

当 CodeCache 达到其容量上限时，JVM 将无法再存储新的编译后的代码。这会导致以下严重后果：

• 编译停止 (Compile Stop): JIT 编译器将停止编译新的热点方法。这意味着程序将退回到解释执行模式，性能会急剧下降。
• 应用性能下降: 由于越来越多的代码无法被编译，应用的整体性能会持续恶化。
• 潜在的 OutOfMemoryError: 虽然 CodeCache 满了本身不会直接抛出 OutOfMemoryError，但它可能会间接导致 OOM。例如，由于性能下降，导致请求处理速度变慢，从而增加了内存占用，最终可能触发 OOM。

3. 为什么 CodeCache 会满？

CodeCache 满的原因有很多，常见的原因包括：

• 代码量大: 应用的代码量非常大，导致需要编译的方法数量也很多。
• 动态代码生成: 应用使用了大量的动态代码生成技术，例如反射、CGLIB 等，这些技术会生成大量的临时类和方法，从而增加了 CodeCache 的压力。
• 频繁的类加载和卸载: 频繁的类加载和卸载会导致 JIT 编译器不断地编译和反编译代码，从而浪费 CodeCache 的空间。
• JIT 编译优化不足: JIT 编译器可能会编译一些不常用的方法，或者编译后的代码效率不高，导致 CodeCache 空间利用率低下。
• CodeCache 大小设置不合理: -XX:ReservedCodeCacheSize 参数设置的 CodeCache 大小不足以满足应用的需要。

4. 如何诊断 CodeCache 满了的问题？

诊断 CodeCache 满了的问题，主要依靠 JVM 的监控工具和日志。常用的方法包括：

• JMX: 使用 JConsole、VisualVM 等 JMX 工具，监控 java.lang:type=MemoryPool,name=Code Cache 内存池的使用情况。如果 CodeCache 的使用率持续接近 100%，则很可能存在 CodeCache 满了的问题。
• JVM 日志: 开启 JVM 的 GC 日志，并关注与 CodeCache 相关的日志信息。例如，可以通过 -XX:+PrintCodeCache 参数打印 CodeCache 的详细信息。
• JFR (Java Flight Recorder): 使用 JFR 记录应用的运行情况，并分析 CodeCache 的使用情况。JFR 提供了丰富的 CodeCache 相关事件，例如 CodeCacheFull 事件。
• Arthas: 使用 Arthas 诊断工具，可以实时监控 CodeCache 的使用情况，并分析 CodeCache 中的代码片段。
• 观察应用行为: 如果应用突然出现性能下降，并且 CPU 使用率没有明显升高，则可能存在 CodeCache 满了的问题。

5. 解决 CodeCache 满了的常见方法

解决 CodeCache 满了的问题，通常需要从以下几个方面入手：

• 增加 CodeCache 的大小: 这是最直接的方法。可以通过 -XX:ReservedCodeCacheSize 参数增加 CodeCache 的大小。例如，-XX:ReservedCodeCacheSize=512m 将 CodeCache 的大小设置为 512MB。需要注意的是，增加 CodeCache 的大小会占用更多的内存，因此需要根据实际情况进行调整。
• 减少代码量: 尽可能减少应用的代码量，例如删除不使用的代码、优化代码结构等。
• 优化动态代码生成: 避免过度使用动态代码生成技术，例如反射、CGLIB 等。如果必须使用这些技术，则需要优化代码生成过程，减少生成的临时类和方法的数量。
• 优化类加载和卸载: 避免频繁的类加载和卸载。如果必须进行类加载和卸载，则需要优化类加载器，减少类加载的开销。
• 优化 JIT 编译: 调整 JIT 编译的参数，例如 -XX:CompileThreshold、-XX:TieredStopAtLevel 等，可以控制 JIT 编译的策略，减少 CodeCache 的压力。
• 使用 -XX:+UseCodeCacheFlushing: 启用 CodeCache Flushing 功能，可以定期清理 CodeCache 中不常用的代码，从而释放 CodeCache 的空间。

接下来，我们将重点介绍 -XX:+UseCodeCacheFlushing 和分层编译阈值调整这两个关键的优化方向。

6. -XX:+UseCodeCacheFlushing：CodeCache 清理的利器

-XX:+UseCodeCacheFlushing 是一个 JVM 参数，用于启用 CodeCache Flushing 功能。该功能允许 JVM 定期清理 CodeCache 中不常用的代码，从而释放 CodeCache 的空间。

工作原理:

CodeCache Flushing 的工作原理是，JVM 会定期扫描 CodeCache，并识别出长时间未被使用的代码片段。然后，JVM 会将这些代码片段标记为“可回收”，并在下次 GC 时将其清理掉。

优点:

• 释放 CodeCache 空间: -XX:+UseCodeCacheFlushing 可以有效地释放 CodeCache 的空间，从而避免 CodeCache 满了的问题。
• 提高 CodeCache 的利用率: 通过清理不常用的代码，可以提高 CodeCache 的利用率，从而提高应用的整体性能。
• 降低 GC 的频率: 由于 CodeCache 的空间得到释放，GC 的频率也会相应降低，从而减少 GC 对应用性能的影响。

缺点:

• 清理代码的开销: 清理 CodeCache 中的代码需要一定的开销，可能会对应用的性能产生一定的影响。
• 代码重新编译的开销: 如果被清理的代码片段再次被调用，则需要重新进行编译，这也会产生一定的开销。

适用场景:

-XX:+UseCodeCacheFlushing 适用于以下场景：

• CodeCache 容易满的应用: 例如，代码量大、动态代码生成多的应用。
• 对性能要求不是非常苛刻的应用: 由于清理代码会产生一定的开销，因此 -XX:+UseCodeCacheFlushing 不太适合对性能要求非常苛刻的应用。

如何使用:

可以通过在 JVM 启动参数中添加 -XX:+UseCodeCacheFlushing 来启用 CodeCache Flushing 功能。例如：

java -XX:+UseCodeCacheFlushing -jar myapp.jar

示例代码:

以下代码演示了如何使用 -XX:+UseCodeCacheFlushing 参数：

public class CodeCacheFlushingExample {

    public static void main(String[] args) throws InterruptedException {
        // 模拟频繁调用一个方法
        for (int i = 0; i < 100000; i++) {
            heavyCalculation(i);
        }

        // 休眠一段时间，让 CodeCache Flushing 有机会清理代码
        Thread.sleep(60000);

        // 再次调用该方法
        for (int i = 0; i < 100000; i++) {
            heavyCalculation(i);
        }

        System.out.println("Done!");
    }

    private static double heavyCalculation(int i) {
        double result = Math.sin(i) + Math.cos(i);
        for (int j = 0; j < 1000; j++) {
            result += Math.sqrt(j + i);
        }
        return result;
    }
}

编译并运行该代码，添加 -XX:+UseCodeCacheFlushing 参数，观察 JVM 日志，可以看到 CodeCache Flushing 的相关信息。

注意事项:

• -XX:+UseCodeCacheFlushing 参数默认是禁用的。
• 启用 -XX:+UseCodeCacheFlushing 参数后，需要根据实际情况进行测试，评估其对应用性能的影响。
• 可以结合其他 CodeCache 相关的参数，例如 -XX:CodeCacheFlushingMinimumCodeCacheSize、-XX:CodeCacheFlushingPercentage 等，进一步控制 CodeCache Flushing 的行为。

7. 分层编译阈值调整：平衡编译速度与代码质量

分层编译 (Tiered Compilation) 是 JVM 的一项优化技术，它将 JIT 编译过程分为多个层次，每个层次使用不同的编译器和优化策略。这样可以平衡编译速度和代码质量，从而提高应用的整体性能。

分层编译的层次:

通常，分层编译分为 5 个层次：

• Level 0 (Interpreter): 解释执行。
• Level 1 (C1 Compiler – Limited Profiling): 使用 C1 编译器进行编译，并进行有限的 Profiling。
• Level 2 (C1 Compiler – Full Profiling): 使用 C1 编译器进行编译，并进行完整的 Profiling。
• Level 3 (C1 Compiler – No Profiling): 使用 C1 编译器进行编译，但不进行 Profiling。
• Level 4 (C2 Compiler): 使用 C2 编译器进行编译。

分层编译阈值:

分层编译的阈值是指，方法需要被调用多少次，才能从一个编译层次提升到下一个编译层次。这些阈值可以通过 JVM 参数进行调整。

常见的阈值参数:

参数	描述	默认值 (HotSpot)
-XX:CompileThreshold	方法需要被调用多少次，才能从解释执行 (Level 0) 提升到 C1 编译 (Level 1)。	10000
-XX:TieredStopAtLevel	指定分层编译停止的层次。例如，-XX:TieredStopAtLevel=1 表示分层编译只到 Level 1，不会使用 C2 编译器。	4
-XX:TieredCompilation	是否启用分层编译。默认启用。	true
-XX:OnStackReplacePercentage	OSR (On-Stack Replacement) 的百分比。OSR 是指在方法执行过程中，如果发现该方法已经满足了编译条件，则可以将该方法替换为编译后的代码。	140
-XX:InterpreterProfilePercentage	解释器 Profiling 的百分比。Profiling 是指在方法执行过程中，收集方法的调用信息，例如调用次数、参数类型等。这些信息可以用于 JIT 编译器进行优化。	33
-XX:ProfiledLoopThreshold	循环需要执行多少次，才能被认为是热点循环，从而触发 OSR。	1000

调整分层编译阈值的影响:

• 降低编译阈值: 例如，降低 -XX:CompileThreshold 的值，可以使更多的代码更快地被编译。这可以提高应用的启动速度和响应速度，但也会增加 CodeCache 的压力。
• 提高编译阈值: 例如，提高 -XX:CompileThreshold 的值，可以减少被编译的代码数量，从而降低 CodeCache 的压力。但这会降低应用的性能，特别是对于一些对性能要求较高的代码。
• 禁用 C2 编译器: 通过设置 -XX:TieredStopAtLevel 的值为 3 或更小，可以禁用 C2 编译器。这可以显著降低 CodeCache 的压力，但也会降低应用的峰值性能。

适用场景:

• CodeCache 容易满的应用: 可以适当提高编译阈值，减少被编译的代码数量。
• 对启动速度要求较高的应用: 可以适当降低编译阈值，使更多的代码更快地被编译。
• 对峰值性能要求不高的应用: 可以禁用 C2 编译器，降低 CodeCache 的压力。

示例代码:

以下代码演示了如何调整分层编译阈值：

public class TieredCompilationExample {

    public static void main(String[] args) throws InterruptedException {
        // 模拟频繁调用一个方法
        for (int i = 0; i < 20000; i++) {
            simpleCalculation(i);
        }

        System.out.println("Done!");
    }

    private static int simpleCalculation(int i) {
        return i * 2;
    }
}

编译并运行该代码，可以通过以下命令调整编译阈值：

java -XX:CompileThreshold=5000 TieredCompilationExample

该命令将 -XX:CompileThreshold 的值设置为 5000，这意味着 simpleCalculation 方法只需要被调用 5000 次，就会被 C1 编译器编译。

注意事项:

• 调整分层编译阈值需要根据实际情况进行测试，评估其对应用性能的影响。
• 可以使用 JFR 或其他性能分析工具，观察 JIT 编译器的行为，从而更好地调整分层编译阈值。
• 需要理解不同编译层次的特点，才能更好地选择合适的编译策略。

8. 其他优化策略

除了 -XX:+UseCodeCacheFlushing 和分层编译阈值调整之外，还有一些其他的优化策略可以用于解决 CodeCache 满了的问题：

• 减少动态代码生成: 尽量避免使用反射、CGLIB 等动态代码生成技术。如果必须使用这些技术，则需要优化代码生成过程，减少生成的临时类和方法的数量。
• 优化类加载和卸载: 避免频繁的类加载和卸载。如果必须进行类加载和卸载，则需要优化类加载器，减少类加载的开销。
• 使用 AOT (Ahead-of-Time) 编译: AOT 编译可以在应用启动之前将代码编译成本地机器码，从而避免 JIT 编译的开销，并减少 CodeCache 的压力。

9. 总结与实践建议

解决 CodeCache 满了的问题需要综合考虑应用的特点、性能需求以及 JVM 的配置。没有一种通用的解决方案，需要根据实际情况进行调整和优化。

• 监控 CodeCache 的使用情况: 使用 JMX、JVM 日志、JFR 等工具，实时监控 CodeCache 的使用情况，及时发现问题。
• 评估优化策略的效果: 在调整 JVM 参数后，需要进行充分的测试，评估其对应用性能的影响。
• 结合多种优化策略: 可以结合多种优化策略，例如 -XX:+UseCodeCacheFlushing、分层编译阈值调整、减少动态代码生成等，从而获得更好的效果。

希望今天的分享对大家有所帮助！下次再见！

简单回顾本次讲座

CodeCache 满了会导致编译停止，影响应用性能。可以通过增加 CodeCache 大小、启用 CodeCache Flushing、调整分层编译阈值等方法来解决。 监控 CodeCache 使用情况并结合多种策略才能达到最佳效果。