跨容器用CRIU恢复Spark Java执行器时JVM崩溃问题求助

一、"In-flight Data"的具体含义 #

在JVM和CRIU的场景中，in-flight data指的是dump操作触发时，进程内部正处于动态处理流程中、状态未完全稳定的数据：

• 对应你遇到的OpenJ9 StringTable断言失败，这类数据可能是StringTable哈希表扩容时的临时条目、正在被修改的字符串引用，或是未完成内存同步的表结构；
• 针对CLASSES组件恢复失败，in-flight data则可能是类加载器正在加载的类元数据、未完成链接/初始化的类信息，或是JVM内部队列中待处理的类加载请求。
  这类数据的特点是没有进入持久化的稳定状态，dump时如果无法完整捕获其上下文（如关联的线程锁、寄存器状态、内存屏障），恢复后JVM无法重建合法的内存结构，直接触发段错误或断言失败。

二、CRIU未捕获的关键组件分析 #

你遇到的"同容器恢复正常、跨容器失败"的核心差异，是跨容器环境下CRIU遗漏了以下与OpenJ9 JVM强绑定的状态：

1. OpenJ9私有内存结构的重定位信息 #

OpenJ9拥有大量自定义内存管理组件（如StringTable、类元数据缓存），这些组件的内部指针依赖进程的虚拟内存布局。跨容器恢复时，即使通过criu-ns修正了PID命名空间，新容器的虚拟内存基地址可能与原容器不同，而CRIU默认对OpenJ9这类非标准内存结构的指针重定位支持不足，导致恢复后JVM访问旧容器的虚拟地址，触发段错误。

2. 容器级命名空间与资源依赖 #

除PID命名空间外，还可能遗漏了：

• IPC命名空间：如果Spark执行器依赖容器内的共享内存段、消息队列等IPC资源，跨容器恢复时这些资源未被迁移，JVM尝试访问时会出现异常；
• 挂载命名空间：JVM加载类依赖的JAR包、临时文件路径在新容器中与原容器不一致，导致CLASSES组件恢复时无法定位类文件，触发加载失败；
• UTS命名空间：部分JVM实现会依赖主机名/域名信息，跨容器时该信息不匹配可能影响内部逻辑。

3. OpenJ9线程同步与TLS状态 #

dump时，JVM内部线程可能持有StringTable或类加载相关的锁，CRIU虽能捕获线程的基本状态，但跨容器恢复时，线程的线程本地存储（TLS）数据、锁对象的内存地址未被正确修正，导致恢复后线程无法正常获取/释放锁，进而引发断言失败。

三、针对性修复建议 #

• 启用CRIU的OpenJ9适配参数：在dump和restore命令中添加--j9参数，CRIU针对OpenJ9的内存结构有专门的重定位逻辑，能有效修复StringTable这类组件的恢复问题；
• 严格保证跨容器环境一致性：
  • 新容器必须使用与原容器完全一致的镜像、JVM版本、Spark版本；
  • 挂载路径、环境变量（JAVA_HOME、SPARK_HOME等）、用户权限要完全匹配；
• 优化dump时机：选择Spark执行器处于空闲状态（无任务运行）时执行dump，尽可能减少in-flight数据的产生；
• 排查CLASSES组件dump细节：使用criu dump -v4生成verbose日志，查看CLASSES组件dump时的详细输出，确认是否存在类文件访问失败、权限不足等问题，针对性修复挂载或文件权限配置。

内容的提问来源于stack exchange，提问作者asi345