JAXB性能优化

 

前言:
　　之前在查阅jaxb相关资料的同时, 也看到了一些关于性能优化的点. 主要集中于对象和xml互转的过程中, 确实有些实实在在需要注意的点. 这边浅谈jaxb性能优化的一个思路.

 

案列:
　　先来构造一个简单的例子:

    @Getter
    @Setter
    @ToString
    @NoArgsConstructor
    @AllArgsConstructor
    @XmlRootElement(name="txn")
    @XmlAccessorType(XmlAccessType.FIELD)
    public static class TNode {

        @XmlElement(name="key", required = true)
        private String key;

        @XmlElement(name="value", required = true)
        private String value;

    }

　　注: 这个基本的映射对象类

	public static <T> String writeAsString(T t) {
        try {
            JAXBContext jc = JAXBContext.newInstance(t.getClass());
            Marshaller marshaller = jc.createMarshaller();
            marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
            marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");

            StringWriter writer = new StringWriter();
            marshaller.marshal(t, writer);
            return writer.toString();
        } catch (JAXBException ex) {
            ex.printStackTrace();
        }
        return null;
    }

　　注: 这是最经典的java对象转化为xml的代码片段.

    @Test
    public void testPref() {

        TNode node = new TNode("key", "value");

        // *) 迭代重复的次数
        int numIter = 1000;
        long startTime = System.currentTimeMillis();
        for ( int i = 0; i < numIter; i++ ) {
            writeAsString(node);
        }
        long endTime = System.currentTimeMillis();

        System.out.println(String.format("iter num: %d, consume: %dms, avg: %.2fms",
                numIter, (endTime - startTime), (endTime - startTime) * 1.0 / numIter));

    }

　　注: 这是实际执行的性能评估代码, 注意这边的迭代次数.

　　测试一下在迭代100/1000/10000次的, 总耗时及平均耗时.

iter num: 100, consume: 2001ms, avg: 20.01ms
iter num: 1000, consume: 11020ms, avg: 11.02ms
iter num: 10000, consume: 108290ms, avg: 10.83ms

　　大致维持在10ms, 这算一个比较酸涩的结果, 如果映射是个复杂的对象, 其耗时会成倍的增加, 对于追求高并发低延时的互联网应用而言, 略显尴尬, redis平均为1ms, mysql/mongo基本维持在10ms范围内. 因此jaxb虽然非常好用, 但是性能需要优化.

 

瓶颈定位&优化:
　　经过测试, 基本聚焦在JAXBContext.newInstance这个方法中. 其生成的JAXBContext实例代价高, 但其是无状态(线程安全), 我们可以想到的一个优化措施是缓存.
　　对转换代码做下小改动:

private static ConcurrentHashMap<Class, JAXBContext> jaxbContMap
    		= new ConcurrentHashMap<Class, JAXBContext>();

public static <T> String writeAsString(T t) {
    try {
        JAXBContext jc = jaxbContMap.get(t.getClass());
        if ( jc == null ) {
            synchronized (t.getClass()) {
                jc = JAXBContext.newInstance(t.getClass());
                jaxbContMap.put(t.getClass(), jc);
            }
        }
        Marshaller marshaller = jc.createMarshaller();
        marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, true);
        marshaller.setProperty(Marshaller.JAXB_ENCODING, "UTF-8");

        StringWriter writer = new StringWriter();
        marshaller.marshal(t, writer);
        return writer.toString();
    } catch (JAXBException ex) {
        ex.printStackTrace();
    }
    return null;
}

　　注: 引入ConcurrentHashMap来缓存类类型到具体的JAXBContext实例.
　　再测试100/1000/10000调用次数的平均时耗, 结果如下:

    iter num: 100, consume: 295ms, avg: 2.95ms
    iter num: 1000, consume: 1325ms, avg: 1.33ms
    iter num: 10000, consume: 5688ms, avg: 0.57ms

　　结果非常令人欣喜, 耗时能够维持在1ms以内, 优化提升效果很明显.

 

总结:
　　总的来说, 这也是jaxb在使用过程的一个坑, 如果线上应用, 切记改为下面的方式优化, ^_^, 本文没有深入研究为何JAXBContext.newInstance代价这么高昂, 只是得出了一个小结论, 权当笔记.