我所在的团队创建了一个数据存储，该数据存储在大型 XML 文档(此处称为消息)中传递信息。在后端，消息被切碎并分块存储在累积中。当调用者请求数据时，这些片段会重新组装成为调用者量身定制的消息。这些模式有些复杂，因此我们无法立即使用 JAXB。该团队(这是几年前的事)认为 DOM 性能不佳。我们现在被埋在一层又一层半破损的解析代码中，这需要几个月的时间才能完成，一旦有人改变模式就会破坏，这让我想把烙铁塞进我的眼球。据我所知，如果我们改用 DOM 方法，很多代码都可以被删除，并且代码库对 future 的变化将更有弹性。我的团队负责人告诉我，使用 DOM 会影响性能，但我找不到任何 2006 年或更早版本以外的数据来验证该假设。
通过 DOM 解析大型 XML 文档是否仍然足够慢，足以承受 XMLBeans 给我们带来的所有痛苦？
编辑1回应您的一些评论:
1)这是一个政府项目，所以我无法摆脱 XML 部分(尽管我真的很想摆脱)。
2) 据我了解，JAXB 的问题与我们模式中存在的替换组有关。另外，也许我应该重申一下 JAXB 的问题，即使用它的努力/返回比率之一。
3) 我正在寻找的是某种最近的数据来支持/反驳这样的论点:使用 XMLBeans 值得我们经历编写无数行脆弱的绑定(bind)代码的痛苦，因为它为我们提供了性能方面的优势。类似于 Joox看起来更容易处理，而且我很确定我们仍然可以在服务器重新组装粉碎的消息并将其发送回调用者之前验证结果。
那么，世界上有没有人知道与此问题相关的任何数据，且该问题的历史不超过五年？
最佳答案
像 XMLBeans 这样的数据绑定(bind)解决方案可以很好地执行，但根据我的经验，如果架构很复杂或经常更改，它们可能会变得非常难以管理。
如果您正在考虑 DOM，那么不要使用 DOM，而应使用其他基于树的 XML 模型之一，例如 JDOM2 或 XOM。它们的设计要好得多。
更好的是(但考虑到您的起点，这可能过于激进)根本不要在 Java 中处理 XML 数据，而是使用 XRX 架构，在该架构中端到端地使用基于 XML 的技术:XProc、XForms、XQuery、XSLT。
根据您的描述，我认为您需要专注于清理应用程序架构而不是性能。一旦你清理了它，性能调查和调整就会变得更加容易。
关于Java XML 解析 DOM 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33047961/