Four XML parsing techniques in Java
In daily work, it is inevitable to use XML as the data storage format. In the face of a wide variety of solutions, which is most suitable for us? In this article, I make an incomplete evaluation of these four mainstream schemes, only for traversing XML, because traversing XML is the most used in work (at least I think).
get set
Test environment: AMD dragon 1.4g OC 1.5g, 256M ddr333, Windows2000 server SP4, sun JDK 1.4 1+Eclipse 2.1+Resin 2.1. 8. Test in debug mode. The XML file format is as follows:
Test method: use JSP end to call bean (for why use JSP to call, please refer to: http://blog.csdn.net/rosen/archive/2004/10/15 /138324. Aspx), let each scheme parse 10K, 100k, 1000K and 10000K XML files respectively, and calculate their consumption time (unit: milliseconds). JSP file:
DOM is the first step in the test (jaxp crimson parser) DOM is the official W3C standard for representing XML documents in a platform and language independent manner. DOM is a collection of nodes or information fragments organized in a hierarchy. This hierarchy allows developers to find specific information in the tree. Analyzing the structure usually requires loading the entire document and constructing a hierarchy before they can do any work. Because it is based on information hierarchy, DOM is considered to be tree based or object-based. Dom and generalized tree based processing have several advantages. First, because the tree is persistent in memory, it can be modified so that the application can make changes to the data and structure. It can also navigate up and down the tree at any time, rather than a one-time process like Sax. DOM is also much simpler to use. On the other hand, for particularly large documents, parsing and loading the whole document may be slow and resource consuming, so it is better to use other means to process such data. These event based models, such as sax. Bean file:
Then there is Sax. The advantages of this processing are very similar to those of streaming media. Analysis can start immediately, rather than waiting for all data to be processed. Moreover, since the application only checks the data when reading the data, it does not need to store the data in memory. This is a huge advantage for large documents. In fact, the application does not even have to parse the entire document; It can stop parsing when a condition is met. In general, Sax is much faster than its replacement dom.
Choose DOM or Sax? For developers who need to write their own code to process XML documents, choosing DOM or Sax parsing model is a very important design decision. DOM uses a tree structure to access XML documents, while Sax uses an event model. The DOM parser converts the XML document into a tree containing its contents, and can traverse the tree. The advantage of parsing the model with DOM is that it is easy to program. Developers only need to call the tree building instruction, and then use navigation APIs to access the required tree nodes to complete the task. You can easily add and modify elements in the tree. However, because the DOM parser needs to process the whole XML document, it requires high performance and memory, especially when encountering large XML files. Because of its traversal ability, DOM parsers are often used in services where XML documents need to change frequently. Sax parser adopts an event-based model. It can trigger a series of events when parsing XML documents. When a given tag is found, it can activate a callback method to tell the method that the tag has been found. Sax usually has low memory requirements because it allows developers to decide which tags to process. Especially when developers only need to process part of the data contained in the document, Sax's extensibility is better reflected. However, when using Sax parser, coding is difficult, and it is difficult to access multiple different data in the same document at the same time.
Bean file:
org.xml.sax.* org.xml.sax.helpers.* javax.xml.parsers.* MyXMLReader java.util.Stack tags = lasting = SAXParserFactory sf = SAXParser sp = MyXMLReader reader = sp.parse( InputSource("data_10k.xml" } System.out.println("运行时间：" + (System.currentTimeMillis() - lasting) + " 毫秒" characters( ch[], start, length) String tag = (tag.equals("NO" System.out.print("车牌号码：" + (tag.equals("ADDR" System.out.println(" 地址:" + }
10k消耗时间：110 47 109 78344 406 375 4223234 3281 3688 331232578 34313 31797 31890 30328
然后是 JDOM http://www.jdom.org/ JDOM 的目的是成为 Java 特定文档模型，它简化与 XML 的交互并且比使用 DOM 实现更快。由于是第一个 Java 特定模型，JDOM 一直得到大力推广和促进。正在考虑通过“Java 规范请求 JSR-102”将它最终用作“Java 标准扩展”。从 2000 年初就已经开始了 JDOM 开发。 JDOM 与 DOM 主要有两方面不同。首先，JDOM 仅使用具体类而不使用接口。这在某些方面简化了 API，但是也限制了灵活性。第二，API 大量使用了 Collections 类，简化了那些已经熟悉这些类的 Java 开发者的使用。 JDOM 文档声明其目的是“使用 20%（或更少）的精力解决 80%（或更多）Java/XML 问题”（根据学习曲线假定为 20%）。JDOM 对于大多数 Java/XML 应用程序来说当然是有用的，并且大多数开发者发现 API 比 DOM 容易理解得多。JDOM 还包括对程序行为的相当广泛检查以防止用户做任何在 XML 中无意义的事。然而，它仍需要您充分理解 XML 以便做一些超出基本的工作（或者甚至理解某些情况下的错误）。这也许是比学习 DOM 或 JDOM 接口都更有意义的工作。 JDOM 自身不包含解析器。它通常使用 SAX2 解析器来解析和验证输入 XML 文档（尽管它还可以将以前构造的 DOM 表示作为输入）。它包含一些转换器以将 JDOM 表示输出成 SAX2 事件流、DOM 模型或 XML 文本文档。JDOM 是在 Apache 许可证变体下发布的开放源码。 Bean文件：
java.io.* java.util.* org.jdom.* org.jdom.input.* lasting = SAXBuilder builder = Document doc = builder.build( File("data_10k.xml" Element foo = List allChildren = ( i=0;i＜allChildren.size();i++ System.out.print("车牌号码:" + ((Element)allChildren.get(i)).getChild("NO" System.out.println(" 车主地址:" + ((Element)allChildren.get(i)).getChild("ADDR" } System.out.println("运行时间：" + (System.currentTimeMillis() - lasting) + " 毫秒" }
10k消耗时间：125 62 187 94704 625 640 76627984 30750 27859 30656
最后是 DOM4J http://dom4j.sourceforge.net/ 虽然 DOM4J 代表了完全独立的开发结果，但最初，它是 JDOM 的一种智能分支。它合并了许多超出基本 XML 文档表示的功能，包括集成的 XPath 支持、XML Schema 支持以及用于大文档或流化文档的基于事件的处理。它还提供了构建文档表示的选项，它通过 DOM4J API 和标准 DOM 接口具有并行访问功能。从 2000 下半年开始，它就一直处于开发之中。 为支持所有这些功能，DOM4J 使用接口和抽象基本类方法。DOM4J 大量使用了 API 中的 Collections 类，但是在许多情况下，它还提供一些替代方法以允许更好的性能或更直接的编码方法。直接好处是，虽然 DOM4J 付出了更复杂的 API 的代价，但是它提供了比 JDOM 大得多的灵活性。 在添加灵活性、XPath 集成和对大文档处理的目标时，DOM4J 的目标与 JDOM 是一样的：针对 Java 开发者的易用性和直观操作。它还致力于成为比 JDOM 更完整的解决方案，实现在本质上处理所有 Java/XML 问题的目标。在完成该目标时，它比 JDOM 更少强调防止不正确的应用程序行为。 DOM4J 是一个非常非常优秀的Java XML API，具有性能优异、功能强大和极端易用使用的特点，同时它也是一个开放源代码的软件。如今你可以看到越来越多的 Java 软件都在使用 DOM4J 来读写 XML，特别值得一提的是连 Sun 的 JAXM 也在用 DOM4J。 Bean文件：
java.io.* java.util.* org.dom4j.* org.dom4j.io.* lasting = File f = File("data_10k.xml" SAXReader reader = Document doc = Element root = (Iterator i = root.elementIterator("VALUE" foo = System.out.print("车牌号码:" + foo.elementText("NO" System.out.println(" 车主地址:" + foo.elementText("ADDR" } System.out.println("运行时间：" + (System.currentTimeMillis() - lasting) + " 毫秒" }
10k消耗时间：109 78 109 31297 359 172 3122281 2359 2344 246920938 19922 20031 21078
JDOM 和 DOM 在性能测试时表现不佳，在测试 10M 文档时内存溢出。在小文档情况下还值得考虑使用 DOM 和 JDOM。虽然 JDOM 的开发者已经说明他们期望在正式发行版前专注性能问题，但是从性能观点来看，它确实没有值得推荐之处。另外，DOM 仍是一个非常好的选择。DOM 实现广泛应用于多种编程语言。它还是许多其它与 XML 相关的标准的基础，因为它正式获得 W3C 推荐（与基于非标准的 Java 模型相对），所以在某些类型的项目中可能也需要它（如在 JavaScript 中使用 DOM）。 SAX表现较好，这要依赖于它特定的解析方式。一个 SAX 检测即将到来的XML流，但并没有载入到内存（当然当XML流被读入时，会有部分文档暂时隐藏在内存中）。 无疑，DOM4J是这场测试的获胜者，目前许多开源项目中大量采用 DOM4J，例如大名鼎鼎的 Hibernate 也用 DOM4J 来读取 XML 配置文件。如果不考虑可移植性，那就采用DOM4J吧！
原文出处：
总结
以上是
编程之家为你收集整理的Java中四种XML解析技术全部内容，希望文章能够帮你解决Java中四种XML解析技术所遇到的程序开发问题。 如果觉得编程之家网站内容还不错，欢迎将编程之家网站推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
- 上一篇：素数_面试中常考下一篇：一道笔试题
猜你在找的Java相关文章
【实战】利用多线程优化查询百万级数据
前言 日常开发中，难免会遇到需要查询到数据库所有记录的业务场景，在索引完善的情况下，当数据量达到百万级别或者以上的时候，全表查询就需要耗费不少的时间，这时候我们可以从以下几个方向着手优化 优化sql
【设计模式】汉堡中的设计模式——观察者模式
【设计模式】汉堡中的设计模式——观察者模式 情景带入 对于爱吃麦当劳的我来说，自然是不想错过各种动态，可是我又不可能【无时无刻】的蹲在店里等新品吧（还是要搬砖的） 那么有没有一种好的方法，在麦当劳【推
@RequestParam，@RequestBody，@ResponseBody，@PathVariable注解的一点小总结
一、前提知识： http协议规定一次请求对应一次响应，根据不同的请求方式，请求的内容会有所不同； 发送GET请求是没有请求体的，参数会直接拼接保留到url后一并发送； 而POST请求是带有请求体的，带
Java中的重载和重写
关于Java中的重载与重写，每一个java人肯定都学习过，这里就再梳理一遍，加深一下印象，忘记的时候拿出来看一看就好了 重载与重写的区别 重载发生在同一个类里面，同一个方法，拥有不同的参数列表，不同的
每日一记：关于Arrays.asList和Collections.unmodifiableList的一点理解
1、正常创建一个List，对List进行操作 List<Integer> collect = Stream.of(1 ,3 ,5 ,7 ,9).collect(Collectors.toL
Java8——Stream流式操作的一点小总结
我发现，自从我学了Stream流式操作之后，工作中使用到的频率还是挺高的，因为stream配合着lambda表达式或者双冒号（::)使用真的是优雅到了极致！今天就简单分（搬）享（运）一下我对strea
性能优化之数据库篇
性能优化-数据库篇1 首先我们要谈论什么是性能？ 吞吐和延迟 没有量化就没有改进 ：监控和度量指标可以指导我们从哪里入手 80/20原则：先优化性能瓶颈的地方 过早的优化是万恶之源：选择合适的优化时机
分布式缓存方案
一、从数据说起 我们再做缓存之前需要把数据先分好类 按变化频率： 静态数据：一般不变的，类似于字典表 准静态数据：变化频率很低，部门结构设置，全国行政区划数据 中间状态数据：一些计算的可复用中间数据，
PHPJavaJava SEPythonNumPyC#C&C++RubyVBasp.NetGoPerlnettygRPCDjangoDelphiJsp.NET CoreSpringFlaskSpringbootSpringMVCLuafastadminLaravelMybatisAspGroovyThinkPHPYii
微信公众号搜 "程序精选"关注
- • 【实战】利用多线程优化查询百
- • 【设计模式】汉堡中的设计模式
- • String s1 = new String("
- • @RequestParam，@RequestBody，
- • Java中的重载和重写
- • elasticsearch7.6.1版本+jsoup
- • 每日一记：关于Arrays.asList和
- • Java8——Stream流式操作的一点
- • 加密配置文件里面的敏感数据
- • 性能优化之数据库篇
- • 分布式缓存方案
- • 超详细kafka教程来啦
- • java-接口和抽象类的联系和区别
- • java-单例详解
- • java网络编程(TCP详解)
- • java网络编程(UDP详解)
- • java集合(List集合与Map集合的
- • java的XML解析(DOM4J技术)
- • 详解java开发环境搭建
- • 利用JAVA实现DES加密算法
- • Java基本类型与包装类详细解析
- • Java打印和打印预览机制实例代
联系我们
Copyright © 2019 编程之家. 当前版本 V7.0.16
编程之家 版权所有 闽ICP备13020303号-8