SAX解析实例：http://www.iteye.com/topic/763895
Java Sax解析是按照xml文件的顺序一步一步的来解析，在解析xml文件之前，我们要先了解xml文件的节点的种类，一种是ElementNode，一种是TextNode。
为了更好地解决大型 XML 处理的问题，Java 开发人员发明了 SAX。SAX 采用事件驱动的方式来处理 XML，它的处理方式是：为每一个元素、属性、内容（这些都认为是事件）定义一个回调方法，这个回调方法由应用程序提供。解析器以数据流的方式读入 XML，当遇到某个元素、属性、内容时就调用相应的回调方法。SAX 的优点是处理效率高，适合处理大型 XML。缺点是 SAX 对 XML 是只读的，不能够对 XML 进行写操作，而且 SAX 处理 XML 中前后相互关联的元素时也没有 DOM 方便，因为应用程序必须自己保留以前事件的状态信息。只会顺序读入所需要的文件内容，不会一次性全部读取，不受文件大小的限制。
但用SAX解析器的时候编码工作会比较困难，而且很难同时访问同一个文档中的多处不同数据。
Dom解析实例：http://www.iteye.com/topic/763926
Dom解析是将xml文件全部载入，组装成一颗dom树，然后通过节点以及节点之间的关系来解析xml文件
DOM 对于 XML 的处理方式就是把整个 XML 读到内存中形成一棵树状结构，然后用各种方法对这棵数进行遍历、插入、删除、修剪等操作。因为 DOM 是 W3C 的正式标准，所有的语言都有支持 DOM 的解析器，包括 Java、C/C++、Perl、JavaScript 等等。DOM 的优点是信息量丰富（全部都在内存中），而且可以随机访问，尤其是在处理前后相互关联的元素时非常方便。DOM 的缺点是 XML 应用程序在处理 XML 之前必须先由 XML 解析器把整个 XML 读进内存并生成树状结构，如果 XML 非常大，例如 10M，解析的过程是非常慢的。如果再加上 XSLT 转换（这是一种必须要使用 DOM 的操作）这类同样耗费资源的操作，可能会耗尽系统的内存资源。所以标准 DOM 只适合于中小型 XML 的处理。
DOM是以层次结构组织的节点或信息片断的集合。这个层次结构允许开发人员在树中寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构，然后才能做任何工作。DOM 以及广义的基于树的处理具有几个优点。首先，由于树在内存中是持久的，因此可以 修改它以便应用程序能对数据和结构作出更改。它还可以在任何时候在树中上下导航，而不是像SAX那样是一次性的处理。
SAX：只能读，不能修改，只能顺序访问，适合对大型的XML的解析，解析速度快！
DOM：不仅能读，还能修改，而且能够实现随机访问，缺点是解析速度慢，只适合解析小型文档
解析速度慢（要在内存中生成节点树，而生成树是比较费时的）
SAX：应用于保存大量数据的XML（为什么要用XML保存大量的数据类容？答：可以实现异构系统
的数据访问，实现跨平台！）
DOM：一般应用与小型的配置XML，方便我们操作！
与DOM 比较而言，SAX是一种轻量型的方法。我们知道，在处理DOM的时候，我们需要读入整个的XML文档，然后在内存中创建DOM树，生成DOM树上的每个 Node对象。当文档比较小的时候，这不会造成什么问题，但是一旦文档大起来，处理DOM就会变得相当费时费力。特别是其对于内存的需求，也将是成倍的增 长，以至于在某些应用中使用DOM是一件很不划算的事（比如在applet中）。这时候，一个较好的替代解决方法就是SAX。
SAX 在概念上与DOM完全不同。首先，不同于DOM的文档驱动，它是事件驱动的，也就是说，它并不需要读入整个文档，而文档的读入过程也就是SAX的解析过程。所谓事件驱动，是指一种基于回调（callback）机制的程序运行方法。在XMLReader接受XML文档，在读入XML 文档的过程中就进行解析，也就是说读入文档的过程和解析的过程是同时进行的，这和DOM区别很大。解析开始之前，需要向XMLReader注册一个 ContentHandler，也就是相当于一个事件监听器，在 ContentHandler中定义了很多方法，比如startDocument()，它定制了当在解析过程中，遇到文档开始时应该处理的事情。当 XMLReader读到合适的内容，就会抛出相应的事件，并把这个事件的处理权代理给ContentHandler，调用其相应的方法进行响应。
如果想结合DOM解析和SAX解析，可以使用JDOM。
关于SAX2，有以下两篇文章：
http://www.blogjava.net/junhong/archive/2006/11/24/83188.html
http://wtnzuodan.blog.163.com/blog/static/955283002008111792141674/
还有一篇没看懂：
http://blog.csdn.net/zgjxwl/article/details/9380079