当java应用程序的性能分析结果（如flamegraph）显示大量时间消耗在`c2compiler::compile_method`中时，这通常意味着jvm的即时（jit）编译器正在忙碌地将热点代码编译成机器码。为了深入了解具体是哪些方法正在被c2编译器编译，从而诊断潜在的性能瓶颈或优化机会，我们可以利用jvm提供的高级诊断工具。
启用JIT编译日志
要追踪JVM的JIT编译活动，特别是C2编译器的行为，最直接有效的方法是使用JVM的-Xlog诊断标志。通过配置此标志，JVM会在运行时输出详细的编译日志到指定文件。
在启动Java应用程序时，添加以下JVM参数：
java -Xlog:jit+compilation=debug:file=comp_log_%p.txt YourApplication
参数解释：
- -Xlog: 这是统一的JVM日志框架前缀。
- jit+compilation: 指定我们要记录JIT编译相关的事件。
- debug: 设置日志级别为debug，以获取最详细的信息。
- file=comp_log_%p.txt: 指定日志输出文件。%p是一个占位符，会被替换为当前Java进程的PID（Process ID），确保每个进程生成独立的日志文件。
执行上述命令后，会在当前工作目录下生成一个名为comp_log_[pid].txt的文件，其中包含了JVM在运行期间进行的所有JIT编译活动的详细记录。
立即学习“Java免费学习笔记（深入）”；
解读编译日志输出
生成的日志文件内容通常会包含多行，每行代表一个编译事件。以下是一个典型的日志输出示例：
[0.032s][debug][jit,compilation] 1 3 java.lang.String::charAt (25 bytes) [0.032s][debug][jit,compilation] 2 3 java.lang.StringLatin1::charAt (15 bytes) [0.033s][debug][jit,compilation] 7 3 java.lang.StringLatin1::hashCode (42 bytes) [0.033s][debug][jit,compilation] 5 3 java.lang.Object::<init> (1 bytes) [0.033s][debug][jit,compilation] 10 3 java.util.ImmutableCollections$SetN::probe (56 bytes) [0.033s][debug][jit,compilation] 6 3 java.lang.String::hashCode (60 bytes) [0.033s][debug][jit,compilation] 12 3 java.lang.StringLatin1::equals (36 bytes) [0.034s][debug][jit,compilation] 9 3 java.lang.Math::floorMod (20 bytes)
日志行的主要组成部分及其含义如下：
- [0.032s]: 时间戳，表示自JVM启动以来经过的秒数。
- [debug][jit,compilation]: 日志级别和标签，表明这是一条JIT编译的调试信息。
- 编译ID: 日志中的第一个数字（例如 1, 2, 7），表示该编译任务的唯一标识符。
-
编译级别: 日志中的第二个数字（例如 3）。这是理解编译类型的关键：
- 级别 1: C1 编译器（Client Compiler）编译，不带Profiling。
- 级别 2: C1 编译器，带方法和分支Profiling。
- 级别 3: C1 编译器，带完整Profiling（默认级别）。
- 级别 4: C2 编译器（Server Compiler）编译，这是我们重点关注的，代表了最高级别的优化。
- 方法签名: 紧随编译级别之后的部分（例如 java.lang.String::charAt (25 bytes)），表示被编译的方法的全限定名及其字节码大小。
因此，当您在日志中看到编译级别为 4 的条目时，就意味着该行记录的方法是由C2编译器进行编译的。
日志符号含义解析
除了上述基本信息，日志中还可能出现一些特殊符号，它们提供了关于编译任务的额外上下文信息：
- %: 表示这是一次OSR（On-Stack Replacement，栈上替换）编译。OSR编译允许JVM在方法执行过程中，将正在执行的解释器代码替换为已编译的机器码，而无需等待方法执行完毕。
- s: 表示被编译的方法是一个synchronized方法。
- !: 表示编译后的代码包含异常处理器。
- b: 表示编译任务是阻塞的，例如由于使用了-Xbatch参数，JVM会等待所有编译任务完成后才开始执行主程序。
- n: 表示被编译的方法是一个native方法。
实际应用与注意事项
通过分析编译日志，您可以：
- 识别热点方法: 找出那些被C2编译器频繁编译或在程序早期就被C2编译的方法，它们通常是应用的核心逻辑或性能瓶颈所在。
- 优化代码: 如果发现某个方法被频繁编译但其性能仍不理想，可能需要审查其代码逻辑，或考虑调整JVM参数。
- 理解JIT行为: 观察JIT编译器在应用程序生命周期中如何逐步优化代码，例如从C1编译升级到C2编译的过程。
注意事项：
- 性能开销: 启用debug级别的JIT编译日志会带来一定的运行时开销，因此不建议在生产环境中长期开启。它主要用于诊断和性能分析。
- 日志大小: 对于长时间运行的应用程序，编译日志文件可能会非常大。请确保有足够的磁盘空间，并在分析完成后及时清理。
- 结合其他工具: 将编译日志与火焰图、JFR（Java Flight Recorder）等其他性能分析工具结合使用，可以获得更全面的性能视图。
总结
当Java应用在C2Compiler::compile_method中表现出高CPU占用时，通过-Xlog:jit+compilation=debug:file=comp_log_%p.txt参数可以有效地追踪并识别出具体是哪些方法正在被C2编译器编译。理解日志输出中的编译级别和各种符号，能够帮助开发者深入洞察JVM的JIT编译行为，从而为性能调优和代码优化提供宝贵的数据支持。这是一个强大的诊断工具，对于深入理解Java应用程序的运行时特性至关重要。
