JDOM解析性能不及DOM：基准测试结果与预期不符的疑问

我完全理解这种预期和实际结果不符的困惑——本来以为JDOM作为轻量的XML解析库会比DOM表现更好，结果JMH测试反而是反向的，这确实让人摸不着头脑。咱们一步步拆解可能的问题：

1. 解析器底层实现的差异 #

• DOM是W3C标准的解析器，很多主流JVM（比如OpenJDK）对其做了底层原生优化，甚至部分逻辑是用C/C++实现的；而JDOM是纯Java编写的上层封装库，本身就会比DOM多一层调用开销。
• 别忘了JDOM的默认解析模式：它默认会构建完整的内存文档树（和DOM逻辑一致），如果你的场景适合流式解析，应该改用JDOM结合SAX的模式（比如SAXBuilder的流式处理），才能发挥它的内存优势。

2. 基准测试代码的潜在问题 #

先把你给出的测试依赖代码格式化出来：

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.runner.Runner;
// ... 剩余代码

然后排查测试代码的几个关键点：

• 对象复用问题：如果你的@Setup方法没有正确复用解析器实例（比如每次基准测试都新建SAXBuilder或DocumentBuilder），JDOM的初始化开销会被放大——DOM的DocumentBuilder可以安全复用，而JDOM的解析器如果重复创建，成本更高。
• 内存测量配置：JMH的内存统计需要开启GC profiling（比如添加-prof gc参数），如果你的测试只是单纯测时间，没有配置内存分析，得到的内存占用数据可能不准确。
• 测试样本大小：如果用的是极小的XML文档，DOM的底层优化会更明显；只有当文档足够大时，JDOM的内存优势才会显现——你是不是用了过小的测试文件？

3. JDOM版本与依赖问题 #

• 版本迭代：JDOM 1.x和2.x的性能差异极大，2.x版本做了大量性能优化。检查一下你的依赖版本，如果是1.x（比如org.jdom:jdom:1.1.3），赶紧换成最新的2.x版本（比如org.jdom:jdom2:2.0.6）试试。
• 依赖冲突：JDOM依赖SAX解析器，如果你的项目里引入了其他SAX实现（比如Apache Xerces），可能和JVM默认的解析器冲突，导致使用了低效的解析逻辑。

4. 解析后的操作开销 #

如果你的基准测试不仅包含解析，还包含解析后的文档操作（比如遍历节点、查询数据），JDOM的API因为封装更友好，会比原生DOM API有更高的开销——DOM的API是最底层的，没有额外封装，这部分差异会拉低JDOM的整体性能。

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