XSLT 3.0链式突发流转换Saxon内存占用异常问题咨询

问题背景 #

我们正在优化XML转XML的多阶段转换流程以降低内存消耗：将多GB级源XML转换为仅原大小10%的内部XML结构。原方案采用基于SAX API的非流式链式转换，现已将4个XSLT阶段调整为burst-streamable，并改用Saxon s9api的Xslt30Transformer（基于Saxon 10.6测试）。

测试500MB源文件时发现：

• 单阶段流式转换仅需不足200MB内存（-Xmx200M即可正常运行）
• 但通过trafo.asDocumentDestination(nextTrafo)链式调用流式转换时，需-Xmx4G才能避免“GC Overhead limit exceeded”错误；即使仅链式2个阶段，单独运行每个阶段200MB足够，链式后仍需4GB

后续观察：

• 设置-Xmx500M时，链式转换可生成约10%的结果文件
• 两个链式转换几乎同时启动，日志前期快速输出，15秒后因GC变慢最终OOM
• 仅加载了3个静态映射小树（与单阶段一致），无其他大内存树

已计划测试最新Saxon 12.x版本，若问题仍存在将提交支持工单。简化调用代码如下：

// trafo1234 are Xslt30Transformer we got using xsltCompiler.compile().load30()

Serializer finalDest = trafo4.newSerializer(Files.newOutputStream(outFile));
StreamSource input = Files.newInputStream(inFile);
trafo1.applyTemplates(input, 
   trafo2.asDocumentDestination( 
      trafo3.asDocumentDestination( 
        trafo4.asDocumentDestination(finalDest))));

问题解答 #

1. 内存暴增是否正常？是否为实现问题？ #

这种内存暴增绝对不正常，属于Saxon在链式流式转换场景下的潜在实现问题（尤其是10.6版本）。

Saxon的asDocumentDestination在连接流式转换阶段时，理论上应该保持流式处理，不会将中间结果全部加载到内存。但在10.x版本中，burst-streamable样式的链式处理可能存在边界情况：

• 当上游阶段的输出节奏与下游阶段的处理节奏不匹配时，可能会在中间缓冲区积累大量未处理的事件，最终导致内存溢出
• 某些burst-streamable的实现细节（比如节点缓存、事件队列）在链式场景下未正确优化，导致内存泄漏或过度占用

2. 更优方案（无需阶段间存磁盘） #

可以尝试以下几种替代方案：

• 升级到Saxon 12.x版本：Saxon在11.x及以后的版本中大幅优化了流式转换的链式处理逻辑，尤其是burst-streamable的内存管理，很大概率能解决该问题
• 使用SequenceTransformer替代手动链式：Saxon s9api提供了SequenceTransformer可以组合多个XSLT阶段，它内部会更高效地处理流式传递，避免手动链式可能的缓冲区问题。示例代码：

  SequenceTransformer sequenceTrafo = new SequenceTransformer(processor);
  sequenceTrafo.setStylesheets(trafo1.getUnderlyingCompiledStylesheet(), 
                               trafo2.getUnderlyingCompiledStylesheet(),
                               trafo3.getUnderlyingCompiledStylesheet(),
                               trafo4.getUnderlyingCompiledStylesheet());
  sequenceTrafo.transform(input, finalDest);
  

• 显式设置阶段间的流式模式：在每个XSLT样式表中确保xsl:output的method为xml且未启用indent（缩进会强制缓存部分节点），同时检查是否存在可能触发节点物化的XSLT构造（比如xsl:copy-of未使用copy-namespaces="no"，或不必要的节点排序）

3. 简便的转换内存占用测量方法 #

无需反复调整-Xmx，可以用以下方法：

• 使用JDK自带工具：
  • jstat -gcutil <pid> 1s：实时查看GC情况，观察Eden、Old区的占用率和GC频率，如果Old区持续上涨且GC频繁，说明内存泄漏或过度占用
  • jmap -heap <pid>：查看堆内存的详细分配，确认哪些区域（比如新生代、老年代）占用过高
• 添加内存监控代码：在转换前后及过程中调用Runtime.getRuntime()相关方法，打印内存变化。示例：

  Runtime rt = Runtime.getRuntime();
  System.out.println("Before: Used=" + (rt.totalMemory()-rt.freeMemory())/1024/1024 + "MB");
  trafo1.applyTemplates(input, ...);
  System.out.println("After: Used=" + (rt.totalMemory()-rt.freeMemory())/1024/1024 + "MB");
  

• 使用Saxon内置的性能分析：启动时添加-DSaxon.performanceTrace=true，Saxon会输出转换过程中的内存使用和事件处理统计，帮助定位哪个阶段导致内存上涨

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