11、JDK 25 新特性：JFR 协作采样（JEP 518）性能监控增强

分类： JDK 25 新特性 2025-11-27 阅读量： 0

你有没有遇到过这种情况，用 JFR 做性能分析的时候，数据看着不太准，有时候甚至能把 JVM 搞崩了？这问题其实挺常见的，特别是那些高并发的应用，线程多、调用栈深，JFR 异步采样的时候经常出岔子。

问题出在哪呢？传统的 JFR 采样是异步的，它会在任意时间点暂停线程来采集调用栈，但这时候线程可能正在执行关键代码，状态不一致，采集到的元数据可能是无效的，结果就是数据不准，严重的时候还会导致 JVM 崩溃。这就像你拍照的时候，被拍的人正在做动作，拍出来的照片肯定是糊的。

JDK 25 里的 JEP 518 就是为了解决这个问题而生的，它引入了协作采样（Cooperative Sampling）机制，只在安全点（Safepoint）采集调用栈。安全点是啥？就是线程处于一致状态的那些特定代码位置，这时候采集数据是安全的，不会出问题。这样既能保证数据准确性，又能避免 JVM 崩溃，还能减少安全点偏差，让性能分析更可靠。

这个特性还新增了一个 jdk.SafepointLatency 事件，可以记录线程到达安全点的时间，帮你分析安全点延迟问题。根据测试，用协作采样后，JFR 的稳定性和可扩展性都提升了不少，特别是在高并发场景下，效果更明显。

传统异步采样的问题

先说说传统异步采样是咋回事吧。JFR 要采集线程调用栈，就得知道线程在执行啥方法，调用栈是啥样的。传统做法是异步采样，就是在任意时间点暂停线程，然后读取线程的调用栈信息。

这听起来挺简单的，但实际上问题不少。第一个问题是线程状态不一致。线程在执行代码的时候，它的状态是动态变化的，调用栈、局部变量、寄存器都在变。如果你在它执行到一半的时候暂停它，读取到的元数据可能是不完整的或者无效的，就像你读一本书的时候，书页正在翻，你读到的内容可能是乱的。

第二个问题是可能导致 JVM 崩溃。如果线程正在执行关键代码，比如正在修改对象头、正在执行 GC 相关操作等，这时候暂停它可能会导致 JVM 内部状态不一致，严重的时候就会崩溃。这就像你开车的时候突然急刹车，可能会出事故。

第三个问题是数据不准确。因为采集到的元数据可能是无效的，所以分析出来的性能数据可能不准确，比如方法执行时间、调用频率等，都可能有问题。这就像你用不准确的秤称重，称出来的重量肯定不对。

第四个问题是安全点偏差。异步采样可能会在某些特定的代码位置采集更多数据，导致分析结果有偏差，不能真实反映应用的性能特征。这就像你调查的时候，只问了某些特定的人群，结果肯定有偏差。

协作采样是咋解决的

协作采样是怎么解决这些问题的呢？核心思路就是只在安全点采集数据，不在任意时间点采集。

安全点是啥？就是 JVM 里那些特定的代码位置，线程执行到这些位置的时候，状态是一致的，可以安全地执行某些操作，比如 GC、线程暂停等。安全点的设计就是为了让 JVM 能在这些位置安全地操作线程，不会出问题。

协作采样就是利用这个机制，只在安全点采集调用栈。这样有几个好处：第一是数据准确，因为线程在安全点的状态是一致的，采集到的元数据是有效的；第二是安全，不会导致 JVM 崩溃，因为安全点本来就是设计来安全操作线程的；第三是减少偏差，因为安全点是均匀分布的，不会在某些特定位置采集更多数据。

具体实现上，JFR 会等待线程到达安全点，然后采集调用栈。这就像你拍照的时候，等被拍的人摆好姿势再拍，拍出来的照片肯定是清晰的。

基本用法

协作采样是默认启用的，你不需要做任何配置就能用。但如果你想控制采样行为，可以用一些 JVM 参数。

# 启用 JFR（默认就启用了，这个参数其实不需要）
java -XX:+FlightRecorder MyApp

# 启用安全点延迟事件，记录线程到达安全点的时间
java -XX:+UnlockDiagnosticVMOptions -XX:+LogSafepointStatistics MyApp

如果你想在代码里控制 JFR 录制，可以这样：

import jdk.jfr.*;

public class JFRExample {
    public static void main(String[] args) throws Exception {
        // 创建一个新的录制，用来记录性能数据
        Recording recording = new Recording();
        
        // 启用协作采样（默认就是启用的，这里只是演示）
        recording.start();  // 开始录制，JFR 会自动使用协作采样
        
        // 你的业务代码
        doWork();  // 执行一些工作，JFR 会在安全点采集调用栈
        
        // 停止录制
        recording.stop();  // 停止录制，数据已经采集完了
        
        // 保存录制数据到文件
        recording.dump(Paths.get("recording.jfr"));  // 把数据保存到文件，方便后续分析
        
        // 关闭录制，释放资源
        recording.close();  // 关闭录制，释放内存
    }
    
    private static void doWork() {
        // 模拟一些工作
        for (int i = 0; i < 1000000; i++) {
            Math.sqrt(i);  // 执行一些计算，JFR 会在安全点采集这些方法的调用栈
        }
    }
}

这个例子展示了怎么用 JFR API 来录制性能数据。Recording 对象用来控制录制，start() 开始录制，stop() 停止录制，dump() 保存数据到文件。协作采样是自动的，你不需要手动控制，JFR 会自动在安全点采集数据。

安全点延迟事件

JEP 518 还新增了一个 jdk.SafepointLatency 事件，可以记录线程到达安全点的时间。这个事件对分析安全点延迟问题很有用，特别是那些对延迟敏感的应用。

import jdk.jfr.*;

@Label("安全点延迟事件")
@Description("记录线程到达安全点的时间")
public class SafepointLatencyExample {
    public static void main(String[] args) throws Exception {
        // 创建一个新的录制
        Recording recording = new Recording();
        
        // 启用安全点延迟事件（需要先启用诊断选项）
        // 注意：这个事件默认是关闭的，需要手动启用
        recording.enable("jdk.SafepointLatency");  // 启用安全点延迟事件
        
        recording.start();  // 开始录制
        
        // 执行一些工作
        doIntensiveWork();  // 执行密集型工作，可能会触发安全点
        
        recording.stop();  // 停止录制
        
        // 保存数据
        recording.dump(Paths.get("safepoint-latency.jfr"));  // 保存到文件
        
        recording.close();  // 关闭录制
    }
    
    private static void doIntensiveWork() {
        // 模拟密集型工作，可能会触发安全点
        for (int i = 0; i < 10000000; i++) {
            // 执行一些计算，可能会触发 GC，从而触发安全点
            new Object();  // 创建对象，可能会触发 GC
        }
    }
}

这个例子展示了怎么启用和记录安全点延迟事件。enable("jdk.SafepointLatency") 用来启用这个事件，然后 JFR 会自动记录线程到达安全点的时间。你可以用 JFR 工具分析这些数据，看看哪些线程到达安全点的时间比较长，从而找出性能瓶颈。

性能影响

协作采样对性能的影响是啥样的呢？理论上，因为只在安全点采集数据，采样频率可能会降低一些，但对应用性能的影响很小，几乎可以忽略不计。

实际上，因为协作采样更安全、更稳定，不会导致 JVM 崩溃，也不会因为采集无效数据而浪费资源，所以整体性能可能还会提升。特别是在高并发场景下，传统异步采样可能会导致线程竞争、锁竞争等问题，协作采样避免了这些问题，性能反而更好。

根据测试，用协作采样后，JFR 的 CPU 开销基本不变，但稳定性和可扩展性都提升了不少。在高并发场景下，传统异步采样可能会导致 JVM 崩溃，协作采样完全避免了这个问题。

实际应用场景

协作采样特别适合哪些场景呢？第一个是高并发应用，线程多、调用栈深，传统异步采样容易出问题，协作采样更稳定。

第二个是对延迟敏感的应用，比如实时交易系统、游戏服务器等，这些应用对延迟要求很高，不能因为性能分析工具导致应用崩溃或性能下降，协作采样更安全。

第三个是需要长时间运行的应用，比如服务器应用，需要持续监控性能，协作采样更稳定，不会因为长时间运行而出问题。

第四个是需要精确性能数据的应用，比如性能基准测试、性能优化等，协作采样提供的数据更准确，分析结果更可靠。

注意事项

用协作采样的时候，有几个注意事项。第一个是采样频率可能会降低，因为只在安全点采集，采样点可能没有传统异步采样那么多。但这通常不是问题，因为安全点是均匀分布的，采集到的数据仍然能准确反映应用性能。

第二个是安全点延迟事件默认是关闭的，需要手动启用。如果你想分析安全点延迟问题，需要先启用诊断选项，然后启用这个事件。

第三个是协作采样是默认启用的，你不需要做任何配置。如果你想禁用（虽然不推荐），可以用 -XX:-UseCooperativeSampling 参数，但这样会回到传统异步采样，可能会有稳定性和准确性问题。

第四个是协作采样和传统异步采样不能同时使用，只能选一个。协作采样是推荐的选项，因为它更安全、更稳定、更准确。

总结

JEP 518 的协作采样机制解决了传统异步采样的很多问题，让 JFR 更稳定、更可靠。通过只在安全点采集数据，避免了线程状态不一致、JVM 崩溃等问题，提高了数据准确性和系统稳定性。

这个特性对高并发应用、对延迟敏感的应用特别有用，能提供更准确的性能数据，帮助开发者更好地分析和优化应用性能。新增的安全点延迟事件也提供了更多分析工具，能帮你找出性能瓶颈。

如果你在用 JFR 做性能分析，建议升级到 JDK 25，用协作采样来获得更稳定、更准确的性能数据。虽然采样频率可能会降低一些，但对大多数应用来说，这不是问题，而且带来的稳定性和准确性提升是值得的。

本文章最后更新于 2025-11-27