java中处理xml数据性能不能大幅提高的根本原因 - 继续追寻高性能xml解析方法

这里讨论的处理xml数据，指包含复杂业务规则处理的场景，基于流的解析方法不在被讨论范围，下面只针对dom模型和xpath进行讨论。

主要原因有：

xml是一种基于string或称文本数据描述方法，描述的是一种逻辑数据结构，不是计算机可以拿来直接进行处理的模型，必须经过解析处理，转换成计算机可以解析的模型（内存结构）。

这个解析过程中包含的主要步骤有（考虑目前主流的dom解析器）：
读入xml string（分派xml原始大小的内存）

扫描该xml string，构建dom，这个过程中会产生数量可观的临时“对象”，是内存利用率高的一个原因。

从string到dom，通常的内存开销大概是原始xml的几十倍到上百倍（曾经做个一个测试，JDK自带W3C DOM，16K的xml string，parsing成dom，内存开销是450K）

xml的处理过程：这里只讨论xpath方法
xpath定位元素的一个隐性问题是，必须从查询起点（比如root节点），根据xpath路径在dom树上逐步级查找。（这似乎是最容易被理解的方法，从未看到过有关于此的质疑声音，个人认为，这种逐级查找的过程实在是有点浪费，尽管开销并不会太大，当今cpu和内存的速度又是这么快，但是如果有一种能直接定位元素的方法（比如工作二维坐标的方法）或许会更好，但这需要抛开“树”的模型，寻找另外一种能表示“树”的数据结构）

xml的输出问题，常见的以xml为核心的处理系统，xml输出问题是必不可少的，无论是输出给外部系统，还是输出给系统内的其他处理组件完成后续处理。xml to string的步骤：
根据dom，进行xml string的输出。这个过程理解上应该是件很简单的事情，做个字符串拼接就完了，另外为了避免java上过多的string对象，可以采用string buffer，理论上似乎不需要太多的内存开销，但实际上恰恰相反，这个xml to string的操作在众多的主流xml解析库上，对内存的需要比parsing xml string还要高（同样一个16K的xml string，从dom到string的过程中，甚至能消耗掉800K）。这就导致如果在系统内大量组件之间传递xml string，势必对性能产生重大影响，所以要极力避免不必要的string于dom间的转换。但是对于跨进程的JVM之间，似乎又只能传递xml string，这又对在不同应用之间使用xml带来了性能的负面影响。所以，需要找到一种计算机能够直接进行处理的模型，避免反复的解析过程，如果突破了这个问题，那么，IT系统绝对会更加绿色。

再总结一下需要解决的问题：

如果找到一种新型的xml处理模型，不需要“重量”的解析过程，就对xml可以直接使用。

这种新的xml处理模型，应该可以非常容易persist或者说“流”化，使不同应用间的计算机系统“直接”可以使用，又不丢失xml结构的精美。

VTD-Xml其实提出了一种非常好的思路，maybe未来会出现更加巧妙的思路，为了绿色IT，让我们共同努力吧！