OpenJDK JFR线程启动事件JVM.statistics与JFR async-profiler采样冲突？JFRNativeSampler与Event-based采样互斥

OpenJDK JFR 线程启动事件 JVM.statistics 与 JFR async-profiler 采样冲突分析

各位早上好/下午好/晚上好！

今天我们来深入探讨一个在性能分析领域经常遇到的问题：OpenJDK JFR（Java Flight Recorder）线程启动事件 JVM.statistics 与 JFR async-profiler 采样之间的冲突，以及 JFRNativeSampler 与基于事件采样的互斥性。这个问题涉及JVM内部机制、JFR的工作原理、以及async-profiler的实现细节，理解它对于准确诊断Java应用的性能瓶颈至关重要。

JFR 线程启动事件与 JVM.statistics

JFR 是 OpenJDK 内置的性能监控和诊断工具，它以低开销的方式记录 JVM 运行时的各种事件。其中，线程启动事件 java.lang.Thread#start (对应 jdk.ThreadStart事件) 用于记录线程的启动过程，而 JVM.statistics 是一种特殊类型的事件，它包含了 JVM 内部各种统计信息，比如 GC 统计、内存使用情况、类加载统计等等。

JVM.statistics 事件的产生依赖于 JVM 内部的计时器和采样机制。当配置 JFR 时，可以设置 jdk.JVMInformation 事件的周期性记录，例如每秒记录一次。这些统计信息对于理解 JVM 的整体健康状况和性能表现非常有帮助。

async-profiler 的采样机制

async-profiler 是一种强大的 Java 性能分析工具，它主要通过两种方式进行采样：

• 基于事件的采样 (Event-based sampling): 通过注册 Linux perf events (例如 PERF_COUNT_HW_CPU_CYCLES、PERF_COUNT_HW_INSTRUCTIONS) 来监控 CPU 周期、指令数等硬件性能计数器。当某个线程的计数器达到预设的阈值时，async-profiler 会中断该线程，并收集调用栈信息。这种方式能够提供非常精确的 CPU 使用情况分析。
• 基于定时器的采样 (Timer-based sampling): 类似于传统的 profiler，async-profiler 周期性地中断所有线程，并收集它们的调用栈信息。这种方式的开销相对较低，但精度也相对较差。

冲突的根源

冲突主要发生在以下两种情况下：

1. JVM.statistics 事件触发频繁的线程启动/停止: 如果 JVM.statistics 事件触发了 JVM 内部创建和销毁大量线程 (例如用于 GC 或者其他内部任务)，那么这些线程的启动和停止事件会产生大量的 JFR 数据。这些数据会占用 JFR 缓冲区，影响其他事件的记录，也可能导致 async-profiler 错过一些重要的采样点。
2. JFRNativeSampler 与基于事件的采样互斥: JFRNativeSampler 是 async-profiler 提供的一种采样模式，它利用 JFR 的事件流来触发采样。在这种模式下，async-profiler 会订阅 JFR 的事件，并在收到事件时进行采样。如果同时启用了基于 Linux perf events 的采样，那么可能会出现冲突，导致采样结果不准确或者 async-profiler 无法正常工作。这是因为 JFR 和 Linux perf events 都在争夺相同的硬件资源，例如 CPU 性能计数器。

详细案例分析

假设我们有一个 Java 应用，它频繁地执行 GC 操作。我们同时启用了 JFR 和 async-profiler，并且 JFR 配置为每秒记录一次 JVM.statistics 事件。

// 模拟频繁 GC 的代码
public class GCExample {
    public static void main(String[] args) throws InterruptedException {
        while (true) {
            byte[] data = new byte[1024 * 1024]; // 1MB
            Thread.sleep(1);
        }
    }
}

在这种情况下，每次 GC 都会导致 JVM 创建和销毁一些线程。这些线程的启动和停止事件会被 JFR 记录下来，并包含在 JVM.statistics 事件中。如果 GC 过于频繁，那么这些事件会占据 JFR 缓冲区的大部分空间，影响其他事件的记录。同时，这些频繁的线程启动和停止也可能干扰 async-profiler 的采样，导致采样结果出现偏差。

更糟糕的是，如果启用了 JFRNativeSampler，那么 async-profiler 会订阅 JFR 的线程启动事件。在这种情况下，每次线程启动都会触发 async-profiler 进行采样。由于 GC 导致的线程启动非常频繁，async-profiler 会被这些采样请求淹没，导致 CPU 使用率升高，甚至崩溃。

代码示例：JFR 配置

以下是一个简单的 JFR 配置文件 (profile.jfr) 的示例：

<?xml version="1.0" encoding="UTF-8"?>
<configuration version="2.0" label="Profiling" description="Configuration for profiling" provider="Custom">
  <control>
    <setting id="sampleinterval">20 ms</setting>
    <setting id="stackdepth">64</setting>
  </control>
  <event path="vm/gc/minor"  throttle="1000 ms"/>
  <event path="vm/gc/major"  throttle="1000 ms"/>
  <event path="java/threads"  throttle="1000 ms"/>
  <event path="jdk/JVMInformation"  period="1 s"/>
  <event path="jdk/ThreadStart" enabled="true"  stackTrace="true"/>
  <event path="jdk/ThreadEnd" enabled="true" stackTrace="true"/>
  <event path="jdk/CPULoad" period="100 ms"/>
</configuration>

在这个配置文件中，jdk/ThreadStart 和 jdk/ThreadEnd 事件被启用，并且 jdk/JVMInformation 事件的周期设置为 1 秒。

解决方案

为了解决 JFR 线程启动事件与 async-profiler 采样之间的冲突，我们可以采取以下措施：

1. 限制 JVM.statistics 事件的频率: 避免过于频繁地记录 JVM.statistics 事件。可以适当增加事件的周期，例如从 1 秒调整到 5 秒或 10 秒。
2. 禁用不必要的线程事件: 如果不需要详细的线程启动和停止信息，可以禁用 jdk/ThreadStart 和 jdk/ThreadEnd 事件。
3. 避免同时使用 JFRNativeSampler 和基于事件的采样: 如果需要使用 async-profiler 进行 CPU 性能分析，建议使用基于定时器的采样方式，或者使用单独的 JFRNativeSampler，而不要同时启用基于 Linux perf events 的采样。
4. 优化 GC 行为: 尽量减少 GC 的频率，例如通过调整 JVM 参数 (例如堆大小、GC 算法) 来优化 GC 行为。
5. 使用 async-profiler 的过滤器: async-profiler 提供了过滤器功能，可以根据线程名、类名等条件来过滤采样结果。可以使用过滤器来排除由 GC 引起的线程启动事件的干扰。

表格总结解决方案

问题	解决方案	备注
频繁的 JVM.statistics 事件	增加 jdk.JVMInformation 事件的周期	降低统计信息记录的频率，减少 JFR 缓冲区的占用。
不必要的线程启动/停止事件	禁用 jdk/ThreadStart 和 jdk/ThreadEnd 事件	减少 JFR 记录的事件数量，降低对 async-profiler 采样的干扰。
JFRNativeSampler 与事件采样冲突	使用基于定时器的采样，或单独使用 JFRNativeSampler	避免 JFR 和 Linux perf events 争夺硬件资源，确保采样结果的准确性。
频繁 GC 导致线程启动	优化 JVM 参数，减少 GC 频率	从根本上减少线程启动的频率，降低对 JFR 和 async-profiler 的影响。
采样结果受线程启动事件干扰	使用 async-profiler 的过滤器	排除由 GC 引起的线程启动事件的干扰，提高采样结果的准确性。

代码示例：async-profiler 过滤器

以下是一个使用 async-profiler 过滤器的示例：

./profiler.sh -d 30 -f profile.html -e cpu -t !GCThread your_application.jar

在这个命令中，-t !GCThread 表示排除线程名包含 "GCThread" 的线程。

JFRNativeSampler 与 Event-based采样互斥的原理深入

JFRNativeSampler 利用 JFR 的事件流作为采样的触发器。它的优势在于可以精确地捕捉到特定事件发生时的程序状态。然而，它与基于 Linux perf events 的采样存在根本性的冲突，原因如下：

• 资源竞争: JFR 和 Linux perf events 都依赖于底层的硬件性能计数器。这些计数器是有限的资源。如果同时启用 JFRNativeSampler 和基于 perf events 的采样，那么它们会争夺这些计数器，导致采样结果不准确或者 async-profiler 无法正常工作。
• 中断处理冲突: 基于 perf events 的采样通过硬件中断来实现。当某个线程的计数器达到阈值时，会触发一个硬件中断，并调用 async-profiler 的中断处理程序。如果同时启用了 JFRNativeSampler，那么 JFR 也会注册自己的中断处理程序。这两个中断处理程序可能会相互干扰，导致系统崩溃或者数据损坏。
• JFR 事件的延迟: JFR 事件的产生和传递需要一定的时间。如果 async-profiler 依赖于 JFR 事件来触发采样，那么采样的时间点可能会有一定的延迟。这种延迟对于某些需要精确时间信息的性能分析场景来说是不可接受的。

因此，为了保证采样结果的准确性和系统的稳定性，建议避免同时使用 JFRNativeSampler 和基于事件的采样。

如何选择合适的采样方式

在选择 JFR 和 async-profiler 的采样方式时，需要根据具体的应用场景和分析需求进行权衡。

• 如果需要对 CPU 使用情况进行精确的分析，建议使用基于 Linux perf events 的采样。这种方式可以提供非常详细的 CPU 周期、指令数等硬件性能指标。
• 如果需要对整个 JVM 的运行时状态进行全面的监控，建议使用 JFR。JFR 可以记录各种 JVM 事件，例如 GC、类加载、线程活动等等。
• 如果需要对特定事件发生时的程序状态进行精确的捕捉，可以使用 JFRNativeSampler。例如，可以使用 JFRNativeSampler 来捕捉到某个异常抛出时的调用栈信息。
• 如果应用对性能开销非常敏感，可以使用基于定时器的采样。这种方式的开销相对较低，但精度也相对较差。

建议在生产环境中进行充分的测试，选择最适合自己应用的采样方式。

结论

理解 JFR 线程启动事件与 async-profiler 采样之间的冲突对于准确诊断 Java 应用的性能问题至关重要。通过限制 JVM.statistics 事件的频率、禁用不必要的线程事件、避免同时使用 JFRNativeSampler 和基于事件的采样、优化 GC 行为、以及使用 async-profiler 的过滤器，可以有效地解决这些冲突，提高性能分析的准确性和效率。根据实际需求选择合适的采样方式，并进行充分的测试验证是关键。

一些关键点回顾

• JFR JVM.statistics 事件可能触发频繁的线程启动/停止，影响 async-profiler 采样。
• JFRNativeSampler 与基于事件的采样会争夺硬件资源，导致冲突。
• 根据应用场景选择合适的采样方式，并进行测试验证。