OpenJ9 CRIU 单线程模式下阻塞操作问题分析与解决

问题背景

在 OpenJ9 虚拟机项目中，CRIU（Checkpoint/Restore In Userspace）功能允许将运行中的 Java 应用程序状态保存到磁盘（检查点），然后在需要时恢复执行。然而，在 JDK24 版本的测试过程中，发现了一个与 CRIU 单线程模式相关的严重问题。

问题现象

测试人员在运行 CRIU 相关测试用例时，观察到了以下关键错误信息：

Caused by: openj9.internal.criu.JVMCheckpointException: Blocking operation is not allowed in CRIU single thread mode.
    at java.base/jdk.internal.ref.PhantomCleanable.<init>(PhantomCleanable.java:77)
    at java.base/jdk.internal.ref.CleanerImpl$PhantomCleanableRef.<init>(CleanerImpl.java:164)
    at java.base/java.lang.ref.Cleaner.register(Cleaner.java:225)

该问题导致多个测试用例失败，包括：

• cmdLineTester_criu_nonPortableRestore_Xtrace_tracepoint_3
• cmdLineTester_criu_nonPortableRestore_0
• cmdLineTester_criu_jitPostRestore_1

技术分析

CRIU 单线程模式限制

在 CRIU 执行检查点操作时，JVM 会进入单线程模式。在这种模式下，任何可能导致线程阻塞的操作都是不允许的，因为这会影响检查点过程的可靠性和一致性。

问题根源

通过分析堆栈跟踪和代码，发现问题出现在以下调用链中：

1. 安全检查提供程序初始化时尝试创建 lambda 表达式
2. 在 lambda 表达式实例化过程中，需要创建 CallSite 对象
3. CallSite 的创建涉及 Cleaner 注册
4. Cleaner 注册过程中会获取同步锁

关键问题点在于：

• CleanerImpl.CleanableList.insert() 是一个同步方法
• 在单线程模式下，获取同步锁可能导致阻塞
• 虽然 PhantomCleanable 构造函数已经标记为 @NotCheckpointSafe，但问题仍然发生

深层原因

进一步分析发现，问题实际上是由两个线程交互引起的：

1. 检查点主线程：尝试执行检查点操作
2. Common-Cleaner 线程：持有 CleanerImpl$CleanableList 锁

当检查点主线程需要获取相同的锁时，由于单线程模式的限制，无法等待锁释放，从而导致异常。

解决方案

针对这个问题，开发团队采取了以下措施：

1. 将 @NotCheckpointSafe 注解正确地应用到非检查点线程可能获取锁的代码路径上
2. 确保在检查点过程中不会与后台清理线程产生锁竞争
3. 修改相关同步机制，避免在单线程模式下产生阻塞

技术影响

这个问题的修复对于 CRIU 功能的稳定性至关重要：

1. 确保了检查点操作可以在各种配置下可靠执行
2. 避免了因后台线程活动导致的检查点失败
3. 提高了 CRIU 功能与 Java 标准库的兼容性

总结

OpenJ9 虚拟机中的 CRIU 功能是一个强大的特性，但在实现上需要特别注意线程和同步机制的处理。这次问题的解决展示了在多线程环境下实现可靠检查点机制的复杂性，以及注解在控制检查点安全性中的重要作用。通过这次修复，OpenJ9 的 CRIU 功能在 JDK24 中的稳定性和可靠性得到了显著提升。