Java 编组器性能

Java marshaller performance

提问by cbz

I've used JAXB Marshaller as well as my own marshaller for marshalling pure java bean objects into XML. It has been observed that both of them require almost same time to marshal. The performance is not acceptable and needs to be improved. What are possible ways where we can improve performance of marshaller? Like threading?

我已经使用 JAXB Marshaller 以及我自己的 marshaller 将纯 java bean 对象编组为 XML。据观察，它们都需要几乎相同的时间进行编组。性能不可接受，需要改进。我们可以通过哪些方式提高编组器的性能？喜欢穿线？

采纳答案by Ben Davies

Seconding the Use of JibX. Like questzen, I found that JibX was 9 times faster than JAXB in my performance tests.

借用 JibX。和 questzen 一样，我发现在我的性能测试中，JibX 比 JAXB 快 9 倍。

Also, make sure you have woodstox on the classpath when using JibX. I found woodstox's Stax Implementation is roughly 1050% faster than the Java6 implementation of Stax.

另外，确保在使用 JibX 时在类路径上有 woodstox。我发现 woodstox 的 Stax 实现比 Stax 的 Java6 实现快大约 1050%。

回答by questzen

In my experience, JIBX http://jibx.sourceforge.net/was nearly 10X faster then JAXB. Yes, I measured it for a performance spec. We used it to bind java beans with large HL7 xml. That being said, the way to improve performance is not to rely on the schema definition but to write custom bindings.

根据我的经验，JIBX http://jibx.sourceforge.net/比 JAXB 快近 10 倍。是的，我根据性能规格对其进行了测量。我们用它来绑定带有大 HL7 xml 的 java bean。话虽如此，提高性能的方法不是依赖模式定义，而是编写自定义绑定。

回答by LiorH

Make sure you create the JaxB context instance only once, creating the context takes some time as it uses reflection to parse the object's annotations.

确保只创建一次 JaxB 上下文实例，创建上下文需要一些时间，因为它使用反射来解析对象的注释。

Note that the JAXBContext is thread safe, but the marshallers\unmarshallers aren't, so you still have to create the marshaller for every thread. However I found that creating the marshallers when you already hold a jaxb context is pretty fast.

请注意，JAXBContext 是线程安全的，但 marshallers\unmarshallers 不是，因此您仍然必须为每个线程创建 marshaller。但是，我发现在您已经拥有 jaxb 上下文时创建编组器非常快。

回答by StaxMan

Byeond other good suggestions, I suggest there is something wrong with the way you use JAXB -- it is generally reasonably well performing as long as:

除了其他好的建议，我建议您使用 JAXB 的方式有问题——它通常表现得相当好，只要：

• You use JAXB version 2 (NEVER ever use obsolete JAXB 1 -- that was horribly slow, useless piece of crap); preferably a recent 2.1.x version from http://jaxb.dev.java.net
• Ensure that you use SAX or Stax source/destination; NEVER use DOM unless you absolute must for interoperability: using DOM will make it 3 - 5x slower, without any benefit (it just doubles object model: POJO -> DOM -> XML; DOM part is completely unnecessary)
• Ideally use fastest SAX/Stax parser available; Woodstox is faster than Sun's bundled Stax processor (and BEA's ref. impl. is buggy, no faster than Sun's)

• 您使用 JAXB 版本 2（永远不要使用过时的 JAXB 1——那太慢了，没用的废话）；最好是来自http://jaxb.dev.java.net的最新 2.1.x 版本
• 确保您使用 SAX 或 Stax 源/目标；永远不要使用 DOM，除非你绝对需要互操作性：使用 DOM 会使它慢 3 - 5 倍，没有任何好处（它只是将对象模型加倍：POJO -> DOM -> XML；DOM 部分是完全没有必要的）
• 理想情况下使用可用的最快的 SAX/Stax 解析器；Woodstox 比 Sun 捆绑的 Stax 处理器快（而且 BEA 的 ref. impl. 有问题，不比 Sun 快）

If JAXB is still more than 50% slower than manually written variant, I would profile it to see what else is going wrong. It should not work slowly when used properly -- I have measured it, continuously, and found it so fast that hand-writing converters is usually not worth time and effort.

如果 JAXB 仍然比手动编写的变体慢 50% 以上，我会分析它以查看还有什么问题。如果使用得当，它的工作速度不会很慢——我不断地测量它，发现它太快了，以至于手写转换器通常不值得花时间和精力。

Jibx is a good package too btw, so I have nothing against trying it out. It might still be bit faster than JAXB; just not 5x or 10x, when both are used correctly.

顺便说一句，Jibx 也是一个很好的包，所以我不反对尝试它。它可能仍然比 JAXB 快一些；当两者都正确使用时，不是 5x 或 10x。

回答by sreeharsha07

We can achieve the performance in Marshalling and unmarshalling by setting the fast booting property at system level. This will give lot of performance improvement.

我们可以通过在系统级别设置快速启动属性来实现编组和解组的性能。这将带来很多性能提升。

System.setProperty("com.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot","true");

System.setProperty("com.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot","true");

回答by David Blake

We have just tracked down a JAXB performance problem related to the default parser configuration used by Xerces. JAXB performance was very slow (30s+) for one data file (<1Mb)

我们刚刚追踪了一个与 Xerces 使用的默认解析器配置相关的 JAXB 性能问题。一个数据文件 (<1Mb) 的 JAXB 性能非常慢 (30s+)

Quoting "How do I change the default parser configuration?" from http://xerces.apache.org/xerces2-j/faq-xni.html

引用“如何更改默认解析器配置？” 来自http://xerces.apache.org/xerces2-j/faq-xni.html

The DOM and SAX parsers decide which parser configuration to use in the following order

1. The org.apache.xerces.xni.parser.XMLParserConfiguration system property is queried for the class name of the parser configuration.
2. If a file called xerces.properties exists in the lib subdirectory of the JRE installation and the org.apache.xerces.xni.parser.XMLParserConfiguration property is defined it, then its value will be read from the file.
3. The org.apache.xerces.xni.parser.XMLParserConfiguration file is requested from the META-INF/services/ directory. This file contains the class name of the parser configuration.
4. The org.apache.xerces.parsers.XIncludeAwareParserConfiguration is used as the default parser configuration.

DOM 和 SAX 解析器按以下顺序决定使用哪个解析器配置

1. 查询 org.apache.xerces.xni.parser.XMLParserConfiguration 系统属性以获取解析器配置的类名。
2. 如果在 JRE 安装的 lib 子目录中存在名为 xerces.properties 的文件，并且定义了 org.apache.xerces.xni.parser.XMLParserConfiguration 属性，则将从文件中读取其值。
3. 从 META-INF/services/ 目录请求 org.apache.xerces.xni.parser.XMLParserConfiguration 文件。该文件包含解析器配置的类名。
4. org.apache.xerces.parsers.XIncludeAwareParserConfiguration 用作默认解析器配置。

Unmarshalling using JAXB results in this algorithm being repeatedly applied. So a huge amount of time can be spent repeatedly scanning the classpath, looking for the configuration file that doesn't exist. The fix is to do option 1, option 2 or option 3 (create the configuration file under META-INF). Anything to prevent the repeated classpath scanning.

使用 JAXB 进行解组会导致重复应用此算法。所以大量的时间可能会花费在重复扫描类路径，寻找不存在的配置文件上。修复方法是执行选项 1、选项 2 或选项 3（在 META-INF 下创建配置文件）。任何防止重复类路径扫描的方法。

Hope this helps someone - it's taken us days to track this down.

希望这对某人有所帮助 - 我们花了几天的时间来追踪这个问题。

回答by IngmarK

If large XML trees are written, providing a BufferedOutputStream to the javax.xml.bind.Marshaller.marshal(Object jaxbElement, java.io.OutputStream os)method made a big difference in my case:

如果编写大型 XML 树，向javax.xml.bind.Marshaller.marshal(Object jaxbElement, java.io.OutputStream os)方法提供 BufferedOutputStream 对 我的情况有很大影响：

The time needed to write a 100MB XML file could be reduced from 130 sec to 7 sec.

编写 100MB XML 文件所需的时间可以从 130 秒减少到 7 秒。