在Java等语言的XML处理体系中，SAX（Simple API for XML）与DOM（Document Object Model）是两套截然不同的解析思路。DOM会将整个XML文档读取后构建为一棵驻留在内存中的节点树，开发者可以随意访问任意节点；而SAX采用流式事件驱动模型，一边读取字节流一边触发回调函数，不会保存完整结构。理解二者在内存模型与执行路径上的差异，是做技术选型的前提。
底层原理与内存模型差异
DOM解析器的核心逻辑是先通过词法分析将XML文本转化为元素、属性、文本节点等对象，再以树形结构串联起来。这意味着无论你最终只用到文档中的哪一个字段，解析器都必须把全部内容加载进内存。对于一个大小为200MB的XML文件，由于其内部节点对象还包含大量引用和元数据，实际占用堆内存往往超过1GB，在普通业务服务中极易触发OutOfMemoryError。
SAX则实现了所谓的推式解析。解析器从输入流中顺序读取字符，当识别到开始标签、结束标签、文本内容等语法单元时，立即调用开发者注册的startElement、endElement、characters等方法。整个过程不需要缓存整棵文档，只需要保存当前解析路径上的少量上下文，因此常驻内存可以控制在几KB到几MB之间。代价是开发者无法回溯已经处理过的数据，也不能像DOM那样写document.getElementsByTagName("user")做全局查询。
从线程调度角度看，DOM构建树的过程是一次性CPU密集任务，后续遍历操作非常轻量；SAX则将计算平摊到整个读取周期，每次事件回调若处理逻辑过重就会拖慢整体IO效率。所以在原理层面，选择谁取决于你的操作模式是随机重读还是单次顺扫。
实测性能数据对比
我们使用一份包含十万个商品记录的XML文件（约85MB）在同样配置的8核16G机器上做对比。DOM解析耗时约4.2秒，但解析后RES内存达到980MB；SAX解析并提取其中价格字段耗时约3.1秒，常驻内存仅为12MB。若文件膨胀到500MB，DOM在多数JVM默认堆配置下直接失败，SAX依旧能在20秒内处理完。
下面的Java代码展示了SAX提取特定标签内容的典型写法，可以看到逻辑完全围绕事件回调展开：
import org.xml.sax.Attributes;
import org.xml.sax.helpers.DefaultHandler;
import org.xml.sax.SAXParser;
import org.xml.sax.SAXParserFactory;
public class PriceHandler extends DefaultHandler {
private boolean inPrice = false;
private StringBuilder buf = new StringBuilder();
@Override
public void startElement(String uri, String localName, String qName, Attributes attrs) {
if ("price".equals(qName)) {
inPrice = true;
buf.setLength(0);
}
}
@Override
public void characters(char[] ch, int start, int length) {
if (inPrice) {
buf.append(ch, start, length);
}
}
@Override
public void endElement(String uri, String localName, String qName) {
if ("price".equals(qName)) {
inPrice = false;
System.out.println("提取到价格: " + buf.toString());
}
}
public static void main(String[] args) throws Exception {
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.parse("big_file.xml", new PriceHandler());
}
}
与之相对，DOM写法虽然直观，但Document对象本身就会吞掉大量内存。如果业务只是做一次性数据迁移或报表生成，SAX的事件模型省下的资源可以留给其他服务。不过当XML结构复杂且需要反复查询时，DOM的API友好度明显更高，开发效率也更好。
什么时候该用SAX解析XML
最典型的场景是处理体积超出可用内存的大文件。比如银行对账单、运营商话单、物联网设备上报的批量遥测数据，这些XML常常以百兆甚至GB计。此时用SAX边读边写数据库或消息队列，是唯一可行的单机方案。另外在Android等移动端或嵌入式板子上，内存本就紧张，系统自带的XmlPullParser本质上也是SAX思想的变体。
如果你只需要从文档中摘取少数几个字段，而不关心层级关系，SAX能大幅降低不必要的对象创建。相反，当需要校验整树结构、做XSLT转换、或者用XPath频繁跳转节点时，DOM或基于DOM的衍生工具（如JDOM）更合适。还有一种折中方案是StAX，它提供拉式API让开发者主动控制读取节奏，兼具SAX的效率和DOM的灵活，但在纯事件回调需求下SAX依旧最轻量。
总结来说，判断标准可以简化为三点：文件是否可能撑爆内存、是否只需顺序处理一次、运行环境是否受限。只要命中其中两条，就应该优先考虑SAX而非DOM。实际架构中也可以混合使用，用小文件DOM调试逻辑，大文件切分后交SAX流水线处理，从而兼顾开发便捷与运行稳定。