測試環境與方法論
- 硬件：Athlon 1GHz, 256MB RAM, RedHat Linux 7.1
- JVM：Sun JDK 1.3.1, HotSpot Client VM, -Xms128m -Xmx128m
- 測試文檔：6 種風格 (莎士比亞戲劇、元素周期表、SOAP、新約聖經、XML 規範)，大小 0.4KB~1MB
- 指標：構建時間、遍歷時間、修改時間、序列化時間、內存佔用、Java 序列化大小/耗時
- 統計：每案例跑 10 次，取最短時間（HotSpot 編譯穩定後）
參賽模型與版本
| 模型 | 版本 | Jar 大小 | 特色 |
|---|
| Crimson DOM | 1.1.1 | 0.2MB | Sun Project X 衍生，JAXP 1.1 內建 |
| Xerces DOM | 1.4.2 | 1.8MB | IBM XML4J 衍生，支援 Schema、延遲節點 |
| Xerces Deferred DOM | 1.4.2 | 1.8MB | 按需展開節點，省內存、加快構建 |
| JDOM | Beta 0.7 | 0.1MB | 純具體類、大量 Collections、易用性優先 |
| dom4j | 0.9 | 0.4MB | 接口+抽象類、XPath 內建、事件流處理大文件 |
| Electric XML (EXML) | 2.2 | 0.05MB | 商業友好許可、刪除無意義空白、XPath 子集 |
| XML Pull Parser (XPP) | 2.0.1b8 | 0.04MB | 拉式解析、最小 API、無實體/註釋/PI 支援 |
關鍵性能發現（摘要）
1. 文檔構建時間
- XPP Pull 模式極快（幾乎不解析），但首次遍歷時補償解析成本。
- Xerces Deferred 在大文檔 (<100KB) 明顯領先；小文檔開銷較大。
- dom4j、XPP(全解析)、Xerces 普通 DOM 綜合接近。
- JDOM、Crimson、EXML 較慢（EXML 受累於空白處理）。
2. 文檔遍歷時間
- XPP 全解析最快，Xerces DOM 約 2 倍，EXML 約 3 倍，dom4j 居中。
- XPP Pull 首次遍歷包含解析，總耗時比全解析慢 20%~100%。
- Xerces Deferred 首次遍歷觸發節點展開，總耗時與普通 DOM 持平。
3. 文檔修改時間
- EXML 領先（因無空白節點可刪），XPP 緊隨，Xerces/dom4j 中游，JDOM/Crimson 墊底。
4. 文本生成 (序列化) 時間
- Xerces DOM 最快但優勢微弱，JDOM 最慢，差異整體 < 2 倍。
5. 內存佔用
- Xerces Deferred 最緊湊（訪問前），dom4j 次之。
- 所有 DOM 模型約佔原始文本 4~6 倍堆內存。
- XPP Pull 訪問前極小，適合超大文件/受限環境。
6. Java 序列化
- dom4j 序列化/反序列化最快、體積最小。
- Xerces DOM 最差（大量微小對象）。
- 建議：跨 JVM 傳遞文檔請用「文本輸出→網絡傳輸→重新解析」，或自定義二進制格式，勿用 Java 序列化。
選型決策樹
- 需驗證/Schema/命名空間/完整 DOM 兼容 → Xerces DOM (或 Deferred)
- 純 Java 專案、重易用性、需 XPath、大文件流式處理 → dom4j
- 中間件/代理/路由、無驗證、極致啟動速度、內存受限、Applet/移動端 → XPP (Pull 模式)
- 教學/遺留維護、小文檔、零依賴 → Crimson DOM (JDK 內建)
- 需商業友好許可、極小體積、可容忍空白丟失 → Electric XML
- 追求 API 簡潔、團隊熟悉 Collections、文檔中等 → JDOM (正式版性能已大幅改善)
遺留提示：JDOM 現狀
文章測試基於 Beta 0.7。JDOM 2.x (2012+) 已重寫核心、支援 XPath、性能大幅提升、成為 Maven Central 高下載量庫，可放心用於新專案。
結語
「沒有最好的模型，只有最合適的模型」。性能只是維度之一；API 風格、生態成熟度、許可證、團隊技能同樣關鍵。建議在專案早期用真實數據跑一次基準測試（參考文中可下載源碼），數據說話，拒絕主觀臆測。
