XML处理看似不会像图像处理那样瞬间吃满堆内存，但在企业集成、Web服务、批量导入等场景中，一次错误的解析策略可能让JVM内存曲线持续走高，最终引发OutOfMemoryError。这类问题常被误认为垃圾回收器不够快，实际上多与文档对象生命周期失控有关。以下从DOM解析模型、SAX/StAX回调、以及解析器工厂复用三个角度分析泄漏成因，并给出可直接落地的规避方案。
为什么DOM解析容易造成内存泄漏
DOM解析模型会把XML文档整体加载到内存，每个元素、属性、文本节点都是独立对象，并且节点之间通过parentNode、firstChild、nextSibling等引用形成双向关联。这意味着只要外部持有一个Node对象（通常是Document），整棵树都处于可达状态，垃圾回收器不会回收其中任何节点。对于几十MB的XML文件，DOM树常用内存可能是原始文件的5到10倍，包括字符串常量、节点对象头、集合开销等。
如果解析后的Document被放入静态HashMap、缓存或ThreadLocal中，即使业务逻辑已经处理完毕，对象仍然通过根引用存活。下面是一个典型错误示例：
public class XmlCache {
private static final Map<String, Document> DOC_CACHE = new HashMap<>();
public void loadAndCache(String key, InputStream in) throws Exception {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(in);
DOC_CACHE.put(key, doc); // 静态Map强引用整棵DOM树
}
}
改进方式是严格控制Document的作用域，只在解析完成后的局部范围内提取必要数据，并让文档对象自然失效。如果确实需要缓存，可以使用WeakReference或限制缓存容量，定期清理超过阈值的条目。下面的代码只提取item节点并转为业务对象，不保留任何Document引用：
public List<Item> parseOnce(InputStream in) throws Exception {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(in);
NodeList nodes = doc.getElementsByTagName("item");
List<Item> items = new ArrayList<>();
for (int i = 0; i < nodes.getLength(); i++) {
Node node = nodes.item(i);
Item item = toItem(node); // 转为轻量业务对象
items.add(item);
}
doc = null; // 显式切断局部强引用，GC可回收整棵树
return items;
}
流式解析不会天然免疫内存泄漏
SAX与StAX事件模型按需读取XML，不需要在堆上建立完整树，对小内存环境友好。但很多人误以为流式解析一定不会泄漏，实际回调里如果保存所有事件数据或复制节点内容，内存消耗甚至会超过DOM。例如自定义DefaultHandler中，把每个元素的文本追加到全局ArrayList，相当于手工构建了一份完整文档副本。
public class LeakyHandler extends DefaultHandler {
private List<String> allText = new ArrayList<>();
@Override
public void characters(char[] ch, int start, int length) throws SAXException {
allText.add(new String(ch, start, length)); // 持续追加，整份文档文本永不释放
}
}
除此之外，XMLStreamReader、XMLReader底层输入流未关闭也会导致堆外内存和文件描述符泄漏，虽然不直接显示为堆对象，但会拖垮进程。正确的做法是在characters方法中只处理当前目标字段，或者在endElement时立即消费并清理StringBuilder。使用StAX时还要确保finally块中关闭读取器：
public void processLargeXml(InputStream in) throws Exception {
XMLInputFactory factory = XMLInputFactory.newInstance();
XMLStreamReader reader = factory.createXMLStreamReader(in);
try {
while (reader.hasNext()) {
int event = reader.next();
if (event == XMLStreamConstants.START_ELEMENT) {
String localName = reader.getLocalName();
if ("price".equals(localName)) {
String price = reader.getElementText();
handlePrice(price); // 直接消费当前字段，不存入全局集合
}
}
}
} finally {
reader.close(); // 必须关闭，释放底层资源
}
}
流式解析的核心优势在于状态可控。处理大型XML时，只保留当前节点的局部变量，事件结束后立刻丢弃。如果业务上需要汇总结果，应把汇总数据设计为紧凑的统计对象，而不是把每个事件原文都放进列表。
解析器工厂与编译对象的复用策略
DocumentBuilderFactory创建DocumentBuilder的代价并不算特别高，但XPathFactory、JAXBContext、SchemaFactory等工厂对象在初始化时会扫描类路径、解析配置、生成类代理，创建一次可能需要几百毫秒甚至数秒。如果每次处理XML都重新创建JAXBContext，不仅CPU高，还会在元数据区留下重复类定义，造成Metaspace膨胀，表现为类似内存泄漏的症状。
正确策略是复用线程安全的工厂和上下文，而避免复用非线程安全的解析器实例。DocumentBuilderFactory通常是线程安全的，但DocumentBuilder不是；JAXBContext线程安全，而Marshaller与Unmarshaller不是。下面的代码保持全局唯一的JAXBContext，每次操作创建局部Unmarshaller：
public class JaxbSupport {
private static final JAXBContext CONTEXT = createContext();
private static JAXBContext createContext() {
try {
return JAXBContext.newInstance(Order.class);
} catch (JAXBException e) {
throw new IllegalStateException(e);
}
}
public Order unmarshal(InputStream in) throws JAXBException {
Unmarshaller unmarshaller = CONTEXT.createUnmarshaller();
return (Order) unmarshaller.unmarshal(in);
}
}
XPathExpression同样应该复用。表达式编译会生成内部语法树和优化结构，频繁编译不仅伤害性能，还容易让不同版本的XPath对象滞留在缓存中。可以借助ConcurrentHashMap缓存已编译的表达式：
private static final Map<String, XPathExpression> XPATH_CACHE = new ConcurrentHashMap<>();
public String evalXPath(Document doc, String expression) throws XPathExpressionException {
XPathExpression expr = XPATH_CACHE.computeIfAbsent(expression, exp -> {
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();
try {
return xpath.compile(exp);
} catch (XPathExpressionException e) {
throw new IllegalStateException(e);
}
});
return expr.evaluate(doc);
}
如果表达式数量过多，缓存本身也可能无限增长。可以换成带最大容量限制的缓存，或者使用WeakHashMap配合SoftReference，让JVM在内存紧张时自动回收旧条目。
用工具定位并验证修复效果
内存泄漏不一定一次就能肉眼发现，尤其是大型系统，需要借助堆转储工具。用jmap -dump:format=b,file=heap.hprof pid导出堆，再用Eclipse MAT或VisualVM的Dominator Tree查看Document、Node、HashMap$Node的引用链。如果发现大量Document对象被某个静态字段间接引用，就说明存在解析结果未释放。
jmap -dump:format=b,file=heap.hprof 1234
分析Dominator Tree时重点观察：哪些对象占据了最大堆空间，它们的GC Root路径是什么，是否经过静态集合或线程本地变量。确认泄漏点后，可以结合前面章节的策略进行改造。还可以使用WeakReference验证修复后对象确实被回收：
Document doc = parseXml();
WeakReference<Document> ref = new WeakReference<>(doc);
doc = null;
System.gc();
Thread.sleep(1000);
if (ref.get() == null) {
// 对象已被回收，说明引用关系已切断
}
除了工具定位，还应建立内存压力测试。使用JUnit重复调用解析接口，观察老年代增长情况。每次循环后记录堆使用量，如果能回到基线说明没有泄漏。注意不要在测试中过度依赖System.gc()，它只作为辅助验证，不应成为生产环境的兜底方案。
总结来说，避免XML处理中的内存泄漏，首先要根据文件规模选择解析模型：大型XML优先使用StAX，需要随机访问时再用DOM并严格控制生命周期；其次是关闭底层输入流，杜绝回调中无限累积事件数据；最后是复用线程安全的工厂与编译对象，避免重复初始化带来的元数据膨胀。配合堆转储分析，大部分XML内存问题都能在测试阶段被提前发现。