Async-profiler在JDK 8/11/17上的JFR转储崩溃问题分析

在Java性能分析领域，async-profiler是一个广泛使用的低开销性能分析工具。然而，在某些特定环境下，特别是使用JDK 8、11和17版本时，该工具在进行JFR格式的性能数据转储时可能会引发JVM崩溃。本文将深入分析这一问题的根源、影响范围以及解决方案。

问题现象

当async-profiler在JDK 8、11或17环境下运行时，特别是在进行CPU采样分析并生成JFR格式的输出文件时，可能会遇到JVM崩溃的情况。崩溃日志中通常会显示类似以下的错误信息：

SIGSEGV (0xb) at pc=0x00007fa5e1ef9108
V [libjvm.so+0x766108] oopDesc::is_a(Klass*) const+0x48
V [libjvm.so+0x7635ec] jvmti_GetClassSignature+0x15c

这种崩溃会导致分析过程中断，无法生成完整的性能分析报告，给用户带来困扰。

根本原因分析

经过深入调查，这个问题源于JVM内部对卸载类处理的一个设计缺陷。具体来说，问题发生在以下场景：

1. async-profiler在采样过程中捕获了某个方法的jmethodID
2. 该方法所属的类及其类加载器随后被卸载
3. 在JVM完全清理相关数据结构之前，async-profiler尝试通过JVMTI接口获取该方法的类签名信息
4. JVM在验证类对象时访问了已被释放的内存，导致段错误

关键点在于，在JDK 8、11和17中，当类被卸载时，JVM不会立即清理相关的jmethodID结构。相反，清理操作会被延迟到下一个安全点(Safepoint)时才执行。这种延迟清理机制在async-profiler转储数据时可能造成时间窗口，导致工具访问到已部分清理的数据结构。

影响范围

这个问题主要影响以下环境组合：

• JDK版本：8、11和17
• 操作系统：所有Linux发行版
• 架构：所有CPU架构
• 容器环境：与容器无关

值得注意的是，在JDK 18及更高版本中，这个问题已经被修复。这是因为JDK-8268364补丁在JVM层面解决了这个问题。

解决方案

针对这个问题，社区已经采取了多方面的解决措施：

1. JDK层面修复：在JDK 18及以上版本中，通过JDK-8268364补丁从根本上解决了这个问题。对于仍在使用JDK 8、11或17的用户，可以考虑升级JVM版本或应用相应的补丁。

2. 工具层面优化：async-profiler也进行了相应的改进，包括：

   • 在使用完jclass后及时调用DeleteLocalRef释放本地引用
   • 探索使用VMStructs直接访问类信息的方式作为备选方案

3. 使用建议：对于必须使用受影响JDK版本的用户，可以采取以下措施降低风险：

   • 缩短单个分析会话的持续时间
   • 避免在分析期间频繁加载/卸载类
   • 考虑使用其他输出格式(如HTML)代替JFR

技术深度解析

从技术实现角度看，这个问题的本质是JVM对类生命周期管理的不足。当类被卸载时，JVM需要确保所有相关的数据结构都被正确清理，或者至少保证外部工具无法访问到这些部分清理的数据。在理想情况下，JVM应该：

1. 在类卸载时原子性地清理所有相关数据结构
2. 或者提供明确的API让工具检测类是否已被卸载
3. 或者保证在类卸载后，所有相关API调用都能安全地失败

当前的解决方案采取了第一种方式，即在类卸载时同步清理所有相关数据结构，消除了工具访问到无效数据的可能性。

总结

async-profiler在JDK 8/11/17上的JFR转储崩溃问题是一个典型的JVM与性能分析工具交互时出现的边界条件问题。通过JDK层面的修复和工具自身的优化，这个问题已经得到了有效解决。对于Java性能分析工程师来说，理解这类问题的根源不仅有助于避免实际工作中的陷阱，也能加深对JVM内部机制的理解。

随着Java生态系统的不断发展，我们期待看到更多类似的工具与JVM协作问题的标准化解决方案，使性能分析工作更加稳定可靠。