本文解析 saxon he 在 web 应用高并发 xslt 转换场景中出现长时间线程阻塞的根本原因，指出其多为采样偏差所致，并重点揭示临时树（temporary tree）滥用导致的隐式同步开销，提供可落地的 xslt 编写规范、线程配置建议与性能调优策略。
本文解析 saxon he 在 web 应用高并发 xslt 转换场景中出现长时间线程阻塞的根本原因，指出其多为采样偏差所致，并重点揭示临时树（temporary tree）滥用导致的隐式同步开销，提供可落地的 xslt 编写规范、线程配置建议与性能调优策略。
在将 Saxon HE 集成到高并发 Java Web 应用（如 Spring Boot）时，若每个 HTTP 请求都触发一次 XSLT 转换，极易观察到线程在 allocateDocumentNumber() 或 updateStatistics() 等 synchronized 方法上“长时间阻塞”。但需明确：这通常不是真实锁竞争，而是 Java 采样式剖析器（如 JFR、Async Profiler）的固有偏差——同步方法天然成为线程暂停（safepoint）的高频采样点，尤其在系统过载时更易被高频捕获。真正的问题往往藏在表象之下：频繁创建临时树（temporary trees），从而被动触发大量文档编号分配与统计更新操作。
? 根源：临时树滥用引发的隐式同步开销
Saxon 为支持 generate-id() 等功能，需为每个非平凡临时树分配唯一文档编号（document number）。该过程由 allocateDocumentNumber() 同步完成；同时，updateStatistics() 会同步更新内部树大小预测模型以优化 GC。二者本身极快，但当临时树数量激增时，同步频次呈线性上升，最终成为性能瓶颈。
最常见的诱因是 XSLT 中不必要地使用结果树片段（RTF）语法：
<!-- ❌ 反模式：强制创建临时树 --> <variable name="items" as="item()*"><for-each select="//book"><copy-of select="."></copy-of></for-each></variable>
即使仅提取简单值，也应避免嵌套 <value-of></value-of>：
<!-- ❌ 低效：生成单文本节点临时树 --> <variable name="title"><value-of select="book/title"></value-of></variable>
✅ 正确写法是直接使用 select 属性，让变量持有序列（sequence）而非树结构：
<!-- ✅ 推荐：零开销，无临时树 --> <variable name="items" select="//book"></variable><variable name="title" select="book/title"></variable>
? 实测表明：修正此类写法可带来 3–5 倍性能提升，并显著降低
allocateDocumentNumber的采样占比。
⚙️ 关键优化措施
-
XSLT 编码规范
- 全面审查变量定义，优先使用
select属性替代内容体（body）； - 避免
<copy-of></copy-of>、<apply-templates></apply-templates>在变量体内无谓使用； - 对静态常量，改用
xsl:param+ 外部传入，避免重复解析。
- 全面审查变量定义，优先使用
-
线程池与并发控制
Saxon XSLT 处理高度 CPU 密集，100 并发线程远超合理阈值。推荐配置：// 示例：基于可用 CPU 核心数的固定线程池 int cpuCores = Runtime.getRuntime().availableProcessors(); ExecutorService transformerPool = Executors.newFixedThreadPool(Math.max(4, cpuCores * 2)); // 保守上限? 注意：Saxon 9.9+ 支持
Configuration.setThreadCount()，但更推荐由应用层统一管控线程资源，避免 JVM 级别线程爆炸。 -
Saxon 实例复用与预编译
-
Processor和XsltCompiler是线程安全且昂贵的对象，必须单例复用； -
XsltExecutable编译后应缓存（如ConcurrentHashMap<string xsltexecutable></string>），禁止每次请求重新编译。
-
-
监控与验证
启用 Saxon 统计日志验证优化效果：processor.setConfigurationProperty( FeatureKeys.TRACE_EXTERNAL_FUNCTIONS, true); // 或通过 JVM 参数：-Dnet.sf.saxon.trace=on观察
TemporaryTree创建次数是否下降，同时配合 JFR 检查safepoint sync time是否收敛。
✅ 总结
Saxon 的“阻塞”表象多源于剖析误判与临时树滥用的双重叠加。真正的优化不在绕过同步，而在消除同步触发条件——通过精准的 XSLT 编写、合理的线程规划与实例复用，可将高并发下的吞吐量提升数倍，同时大幅降低 GC 压力与响应延迟。切记：在 XML 处理领域，“少创建，多复用，直序列，避 RTF” 是高性能的黄金法则。
