关于高性能xml解析问题的再思考

如今xml应用已经遍布天下，您是否还在您的应用中使用传统的SAX或DOM技术呢？回答yes是没有关系的，但问题是您有没有想过进一步提升xml的处理速度，减少内存使用率，使您的应用处理模型变得更为简化呢？

 

周末花了点时间来研究了一下这个问题，但似乎还没有找到更好的答案，：（，如果哪位高人有好的建议，欢迎交流！

 

一点背景：

本人近些年一直奋斗在电信行业BSS应用集成的一线，致力于简单、高性能、灵活的EAI架构的研究，在应用xml过程中，为提供统一的、简化的、可配置化的xml访问方法，基本只使用dom+xpath，在实现数据转换功能方面，架构于dom+xpath只上的框架堪称完美，几乎胜任任意复杂结构的xml转换需求，截止目前，该框架还未发现应对不了的情况。

 

高性能xml处理需求的起源：

该框架已经在多个项目应用过程中在对xml处理上进行了大量的性能调整，能够满足苛刻的应用集成需求，实际评测，性能大大优于主流国外厂商eai/esb产品。

 

但最近在思考将该框架应用于大型Web应用中作为后台服务总线时，对于xml处理的开销产生了些许担忧，因为作为大型web应用的服务提供端，需要承载的并发压力要远远高于应用集成场景。

【实际测试参考： 一个查询列表操作，从后台DB中获取一个列表数据，约16K，整个操作从接受http请求到返回http response，服务端memory消耗（垃圾对象）约4.5m，其中dom对象转string，一次消耗约450k，共进行2次输出，当然还有些其他操作】

 

新兴xml解析方法：

近些年诞生了一些新的xml解析方法，主要是基于stream的解析技术和基于index的解析技术。

大概看了下这方面的文档，这种新兴的解析方法确实很有创新性，但距离我需要达到的目标，还有些局限。（注：我的需求是可以基于xpath在输入的xml消息上进行较复杂的操作，对于同一个element，可能需要读取多次，进行重复读取）

 

1）先说基于stream的解析，StAX: JAXP1.4 新成员，基于“拉”技术的xml解析，提供基于指针和基于事件（迭代器）的两种类别API。局限是xml节点只能被扫面一次，不可重复读取，适用于简单的xml处理逻辑。（其实所有的流技术都有这个元素只能单一读取一次的问题，不适合拿xml作为内存结构进行复杂运算的场合。)

 

2）基于index技术的解析，代表作为VTD-xml，这种技术原理上是保留从输入读取的原始xml字节数组（不允许对此内容进行更改），执行解析动作后，创建virtual table，填充所有xml节点信息的index，对xml的所有操作均通过index进行。这种技术具备最小的内存使用率（在当今主流的sax和dom解析器中）和极高的效率，并且支持xpath，比较适合适用xml作为只读型内存结构。不过不太适合创建xml文档（尤其是基于xpath创建xml文档）。尽管vtd支持对xml的修改，但目前还未仔细研究过其内部实现，不太清楚对xml进行大量内容更新操作的效率，另外，vtd在创建新xml文档方面，api比较青涩，XMLModifier在每次操作后需要重新定位index，再插入新的element，使用起来不是很方便。不过，可以得出的结论是，对于需要使用xml作为内存结构，并在其上进行复杂逻辑操作、对元素有重复读取的场合，整个文档读入内存后进行处理是必要的，如果强行使用流技术，必须进行特殊处理，对相应的元素进行缓存，以便后续引用。

 

另外，在进行复杂xml转换时，通常需要根据输入，生成一个新的xml文档，很少是在原文档上进行修改，所以使用vtd-xml，如果有一个牛X的xml生成技术配合就天衣无缝了。看了下一个老外整的WAX（writing api for xml），简单是简单，不过无法支持基于xpath生成，API生成节点时，还必须按顺序，也不太适合我的要求。看来，有时间需要想想自己实现一个了。

 

VTD-xml的xpath，个人觉得局限主要在不支持xpath相对路径。如果进行复杂的xml处理，了解相邻节点的层次关系是非常重要的，常常需要将指针定位于某个element，然后通过xpath相对路径进行小范围操作，好像VTD-xml还不能很好的支持。

 

3）Streaming XPath Processing：这个话题起源似乎就比较早了，看了网上不少资料，不乏中科大、南京大学、某某重点试验室的研究生论文研究过这个问题，后来也看了些国外的论文，似乎如出一辙，不知道是否有抄袭之嫌。扯远了，这个解析方法主要是定义一组xpath作为规则，通过定义好的编译器生成自动机，当xml输入时，通过SAX引擎产生事件，驱动自动机运行，即可得出结果。代表作有YFilter。个人感觉这种方法也是基于xml 流技术，相信也存在元素重复读取的限制，不可考虑不同xml元素间的逻辑关系，故未作深入研究，如有错误，欢迎指正。