在处理XML数据时，SAX和DOM是两种最常被提及的解析模型。SAX全称为Simple API for XML，它并不把整个文档加载到内存，而是以流的方式顺序读取；DOM全称为Document Object Model，它会把XML文档转换为由节点组成的树结构。两者在内存消耗、访问方式、修改能力上存在本质区别，理解这些差异有助于避免性能隐患。
简单来说，如果需要快速抽取大文件中的部分数据，SAX往往是更好的选择；如果需要在内存中频繁增删改查XML节点，DOM的树模型则更加直观。下面从原理和代码层面展开分析。
一、SAX解析：基于事件驱动的流式处理
SAX解析器的工作方式可以理解为逐段扫描。它从XML文档的开头开始，按顺序读取每个字符，遇到标记时触发相应的事件。这些事件包括文档开始、元素开始、元素结束、文本内容、注释等。开发者需要实现一个处理器，在相应方法中编写业务逻辑。解析器不会自动保存已经读过的内容，除非开发者在回调中主动把数据存下来。
常见的回调方法有startDocument、startElement、characters、endElement和endDocument。例如当解析器遇到<book>开始标签时，会调用startElement方法，并把元素名和属性传进去；遇到文本内容时触发characters方法；遇到</book>结束标签时触发endElement方法。整个过程中，应用代码需要自行维护当前正在处理哪个元素、需要提取哪些数据，这对状态管理提出了一定要求。
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.DefaultHandler;
import javax.xml.parsers.SAXParser;
import javax.xml.parsers.SAXParserFactory;
public class SaxDemo {
public static void main(String[] args) throws Exception {
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
DefaultHandler handler = new DefaultHandler() {
@Override
public void startElement(String uri, String localName, String qName, Attributes attributes) {
System.out.println("开始元素: " + qName);
}
@Override
public void characters(char[] ch, int start, int length) {
String text = new String(ch, start, length).trim();
if (!text.isEmpty()) {
System.out.println("文本内容: " + text);
}
}
@Override
public void endElement(String uri, String localName, String qName) {
System.out.println("结束元素: " + qName);
}
};
parser.parse("books.xml", handler);
}
}
这段代码展示了SAX解析的基本结构。处理器继承自DefaultHandler，只重写了三个核心方法。实际项目中如果需要提取特定元素的数据，通常会在startElement中判断元素名是否匹配，在characters中拼接文本，在endElement中完成一个完整节点的处理。由于SAX不保存文档结构，这种写法非常适合只需要读取一次、不需要回退或随机访问的场景。
SAX的最大优势是内存占用极低。解析器在任意时刻只持有当前读取位置附近的小块数据，因此即使处理数GB的XML文件，内存使用量也不会随着文档体积线性增长。它的缺点是编程模型相对繁琐，无法直接定位到文档中某个节点，也不能修改XML内容。如果业务逻辑需要在多个元素之间做复杂关联，开发者必须自己维护栈或状态机，代码复杂度会明显上升。
二、DOM解析：构建内存中的节点树
DOM解析器采用完全不同的策略。它会把整个XML文档一次性读入内存，并按照文档的层级关系构建一棵树。树中的每个节点都对应XML中的一个元素、属性、文本或注释。开发者通过Document对象获取根节点，然后可以随时遍历任意分支、修改节点内容、添加或删除节点。这种模型更符合面向对象的编程习惯，理解起来也比较直观。
使用标准Java API进行DOM解析时，通常先通过DocumentBuilderFactory创建DocumentBuilder，再调用parse方法生成Document对象。之后可以使用getElementsByTagName获取所有指定名称的元素，也可以通过getFirstChild、getNextSibling等方法手动遍历树。下面的例子演示了读取所有标题节点并输出文本内容。
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
public class DomDemo {
public static void main(String[] args) throws Exception {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse("books.xml");
NodeList titles = doc.getElementsByTagName("title");
for (int i = 0; i < titles.getLength(); i++) {
Element title = (Element) titles.item(i);
System.out.println(title.getTextContent());
}
}
}
在这段代码中，doc.getElementsByTagName("title")会返回文档中所有<title>元素的列表。因为DOM已经把整棵树加载到内存，所以可以多次调用、随机访问任意节点。这是SAX做不到的。DOM树还支持写操作，例如createElement、appendChild、setAttribute等，修改完成后还可以通过Transformer将树重新写回XML文件。
DOM的主要缺点是内存开销大。解析过程中需要为每个节点创建对象，同时还要维护父子、兄弟等引用关系，通常内存占用会达到原始XML文件大小的数倍甚至十几倍。如果XML文件很大，很容易触发堆内存溢出。此外，构建完整树结构也需要更多时间和CPU资源，对于只需要读取少量数据的场景来说并不划算。DOM更适合中小型文档、需要频繁修改或多次遍历的用例。
三、SAX与DOM的核心差异对比
从处理模型上看，SAX是推式解析，解析器主动调用事件处理器，应用代码处于被动响应状态；DOM则是解析完成后由应用代码主动查询树结构。这种差异决定了它们在很多维度上的表现截然不同。下面用表格列举几个关键对比点。
| 对比维度 | SAX | DOM |
|---|---|---|
| 内存占用 | 低，与文档大小无关 | 高，与文档节点数成正比 |
| 访问方式 | 顺序只读，无随机访问 | 可随机访问任意节点 |
| 文档修改 | 不支持 | 支持增删改 |
| 解析速度 | 较快，边读边处理 | 较慢，需完整构建树 |
| 编程复杂度 | 事件驱动，状态管理复杂 | 树遍历直观，API丰富 |
| 适用文档规模 | 大文件、流式数据 | 中小文件、需频繁操作 |
内存差异是两者最显著的分界线。以100MB的XML文件为例，使用SAX解析时，JVM堆内存可能只需要几十MB，因为数据是流式进入的。而使用DOM解析时，除了保留原始文本内容，还要为每个节点创建对象、维护层级关系，实际占用往往超过500MB甚至更多。对于运行在容器或移动设备上的应用，这种差距直接决定程序能否正常运行。
访问模式同样重要。SAX只能前进，不能后退，也不能重复读取某个节点，除非开发者把所有感兴趣的数据都保存到自定义数据结构中。DOM则天然支持重复遍历和随机访问，可以通过XPath快速定位节点。如果业务逻辑需要先统计某些值、再根据统计结果修改文档，DOM显然是更合适的选择；而如果只是从日志或消息流中提取某些字段，SAX的流式处理反而更高效。
在解析速度方面，SAX通常比DOM更快，因为它不需要创建完整对象图。但是对于相同文档的多次解析，DOM只需要构建一次树，后续操作只是遍历内存对象；SAX则每次都要重新扫描整个文档。因此如果同一份XML需要被反复读取，DOM的总开销可能更低。实际项目中需要结合访问频率和文档大小综合判断。
四、实际项目中的选择策略与避坑指南
场景决定选型。如果面对的是大型日志文件、数据导出包、消息队列中的XML报文，且只需要提取其中的若干字段，SAX是更稳妥的方案。它的低内存特性可以避免服务器出现偶发性内存告警。例如在处理几GB的订单数据时，用SAX流式提取订单号和金额，处理完一条就释放一条，进程可以长时间稳定运行。而如果业务需要解析小型配置文件、修改节点后写回、或者使用XPath做复杂查询，DOM的树模型会让代码更清晰、更易维护。
一个常见的误区是在处理大文件时直接使用DOM解析。有些开发者觉得DOM代码写起来简单，于是把几百MB的XML文件交给DocumentBuilder，结果很快遇到OutOfMemoryError。此时并不是代码逻辑有问题，而是解析策略根本不适合文档规模。解决办法要么改为SAX流式处理，要么结合StAX这种拉式解析器，在需要时逐个读取节点，兼顾编程便利性和内存控制。
另一个容易忽略的问题是SAX中的状态管理。由于SAX的事件是分散的，同一个元素的内容可能被拆成多次characters回调，尤其是文本中包含实体引用或换行时。如果代码中只是简单地把每次回调的文本赋值给变量，最后可能只得到部分内容。正确做法是使用StringBuilder在characters中追加，在endElement中再取出完整文本。此外，如果需要在SAX中实现提前终止解析，可以抛出SAXException，但这会中断整个解析流程，使用时需要谨慎。
综合来看，SAX适合一次性读取、顺序处理、对内存敏感的场景；DOM适合需要随机访问、修改文档、且文档体积可控的场景。理解两者的内部机制和适用边界，能够帮助开发者在面对不同XML处理需求时迅速做出正确决策，避免不必要的性能损耗和内存风险。