Java 8升Java 17后微服务OOM：UnmarshallingContext内存泄漏排查求助

1. JAXB 实现版本或配置冲突 #

Java 8 中 JAXB 是 JDK 内置组件，但 Java 11+ 已移除该模块，Spring Boot 会通过引入第三方依赖（如 com.sun.xml.bind:jaxb-ri）提供实现。如果升级后依赖版本与当前 Spring Boot 版本（适配 Java 17 的版本）不兼容，或是存在重复依赖导致类加载冲突，可能触发 UnmarshallingContext 的内存泄漏 Bug，导致实例无法正常回收。
建议检查 jaxb-core、jaxb-impl 等相关依赖的版本，清理重复引入的依赖项。

2. JAXB 资源未正确释放 #

即使你的代码没有直接调用 JAXB，框架或第三方组件也可能在批量处理中隐式使用它（比如 XML 配置加载、消息解析）。如果批量循环中每次创建新的 Unmarshaller 却未调用 close() 方法，或是未用 try-with-resources 包裹资源，会导致 UnmarshallingContext 实例持续堆积。
示例正确写法：

try (Unmarshaller unmarshaller = jaxbContext.createUnmarshaller()) {
    // 执行 XML 解析逻辑
} catch (JAXBException e) {
    // 异常处理
}

3. GC 策略变更的影响 #

Java 17 默认使用 ZGC（Linux 64 位环境）或 G1GC，而 Java 8 默认是 ParallelGC。不同 GC 策略的对象回收时机、判定逻辑存在差异，可能导致原本在 Java 8 中能被及时回收的 UnmarshallingContext 对象，在 Java 17 中被延迟回收，批量处理时堆积触发 OOM。
可以临时切换回 ParallelGC 测试，添加 JVM 参数：-XX:+UseParallelGC，观察问题是否复现。

4. 类加载器隔离导致的引用泄漏 #

org.springframework.boot.loader.LaunchedURLClassLoader 是 Spring Boot 的启动类加载器，如果 JAXB 相关类被此类加载器加载，而批量处理中创建的 UnmarshallingContext 实例被其他类加载器持有的对象引用，会形成跨类加载器的无效引用，导致 GC 无法回收这些实例。
检查是否存在自定义类加载逻辑，或是第三方组件使用了独立类加载器，导致 JAXB 上下文无法正常清理。

5. 批量数据的隐性变化 #

升级 Java 版本后，可能伴随业务数据规模增长，或是 XML 数据结构变更（比如新增大量嵌套节点），导致单条记录解析后的对象内存占用上升，批量处理时总内存超出堆限制。此时堆转储中 UnmarshallingContext 占比高，可能是因为它持有了大量解析后的对象引用。
对比升级前后的批量数据量、单条 XML 大小，计算总内存占用是否超过当前堆配置。

6. JVM 堆内存配置遗漏 #

Java 17 对堆内存的默认配置与 Java 8 存在差异，比如 Java 8 默认堆大小为物理内存的 1/4，而 Java 17 会因 GC 策略调整默认值。如果升级后未重新调整 -Xmx、-Xms 等参数，可能导致堆内存不足以支撑批量处理需求。
检查当前 JVM 堆内存配置，与 Java 8 时期的配置对比，按需调整堆大小参数。

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