Spring Integration 解组转换器 Jaxb2Marshaller 性能问题答案

【问题标题】：Spring Integration unmarshalling transformer Jaxb2Marshaller performance concernSpring Integration 解组转换器 Jaxb2Marshaller 性能问题
【发布时间】：2015-01-14 15:16:26
【问题描述】：

目前我们的应用程序没有利用 spring 集成提供的 xml 转换器。相反，它创建一个 JaxbContext，然后从该 JaxbContext 创建一个 JAXB 解组器/编组器池并将它们连接到服务激活器中。我们创建池是为了不产生为每个操作创建编组器和解组器的成本。

作为重构工作的一部分，我们决定应该使用 xml 转换器。在尝试实现时，我们发现 org.spring.oxm.Marshaller 实现不支持编组器/解组器的池化，因为 Spring 集成的 UnmarshallingTransformer 期望和实现 org.spring.oxm.Marshaller。 org.spring.oxm.Marshaller 的每个实现都会在调用 unmarshal 方法时创建一个新的 javax.xml.bind.Unmarshaller

最后，我已经为我的问题提供了足够的背景信息。为每个解组操作创建一个新的解组器不是性能问题吗？根据jaxb ri documentation，它确实会影响性能。作为反论点，jaxb 项目states 的领导认为它们是轻量级的

【问题讨论】：

似乎您已经回答了自己的问题 - YMMV。谨防过早的优化。
@closer 这不是基于意见的。

标签： java spring jaxb marshalling spring-integration

【解决方案1】：

也许，一个好主意是将编组器转移到 java。对不同的对象和验证处理程序使用 Marshaller 真的很繁重，而且是最吃内存的怪物之一。

【讨论】：

【解决方案2】：

您可以安全地重用 JAXBContext，但我从未见过保证 Marshaller 和 Unmarshaller 实例是线程安全的和/或可重用的。

这实质上意味着您不能保证池化编组器/解组器是安全的。这将是不汇集它们的充分理由。

我也怀疑这是否会带来很大的性能提升。 Marshallers/unmarshallers 保持当前的 marshalling/unmarshalling 状态，因此通过重用 marshallers/unmarshallers 并没有太多可节省的空间。

【讨论】：