Java 中的 XML：文檔模型，第一部分：效能

	Java 中的 XML：文檔模型，第一部分：效能		英文原文

內容： 文檔模型 DOM JDOM dom4j Electric XML XML Pull Parser 測試詳細資料 效能比較 文檔時間 文檔遍曆時間 文檔修改時間 文本產生時間 文檔記憶體大小 Java 序列化 結束語 後續內容... 參考資料 關於作者 對本文的評價 相關內容： 教程：Understanding SAX 教程：Understanding DOM 教程：XML programming in Java 另外在 Web 服務專區： 教程 工具和產品 文章 研究 Java 中 XML 文檔模型的特性和效能 Dennis M. Sosnoski（dms@sosnoski.com） 總裁，Sosnoski Software Solutions, Inc. 2001 年 9 月 在本文中，Java 顧問 Dennis Sosnoski 比較幾個 Java 文檔模型的效能和功能。當選擇模型時，無法做到每次都權衡得很清楚，如果以後改變主意，則需要大量編碼來進行切換。作者將效能結果放入特性集合的上下文中並遵循標準，對所要求的正確選擇給出了一些建議。本文包含用於這組測試的幾張圖表和原始碼。 使用記憶體中 XML 文檔的 Java 開發人員可以選擇使用標準 DOM 表示或幾個 Java 特定模型中的任何一個。該靈活性已經協助將 Java 建立成 XML 工作的出色平台。但是，由於不同模型數量的增加，已經更加難以確定如何比較模型的功能、效能和易用性。 關於使用“Java 中的 XML”系列中的第一篇文章研究了 Java 中一些領先的 XML 文檔模型的特性和效能。它包括一組效能測試的結果(帶有可下載的測試代碼，請參閱參考資料）。在系列中的第二篇文章將通過比較為實現同樣任務所使用的不同模型的樣本代碼來研究易用性問題。 文檔模型 Java 中的可用文檔模型數一直在增加。對於本文，我已經涵蓋了最常用的模型和幾項選擇，這示範了那些可能還未被廣泛瞭解或使用的特別令人感興趣的特性。隨著“XML 名稱空間”的重要性增加，我已經包含了僅支援該功能的模型。下面列出了帶有簡要介紹和版本資訊的模型。 僅為說明本文中所使用的術語： 解析器是指解釋 XML 常值文檔結構的程式 文檔表示是指程式用於記憶體中文檔的資料結構 文檔模型是指支援使用文檔表示的庫和 API 某些 XML 應用程式根本不需要使用文檔模型。如果應用程式可以通過文檔的一次遍曆搜集它需要的資訊，則可能直接使用解析器。該方法可能需要增加一些工作量，但是它的效能總是優於在記憶體中構建文檔表示。 DOM DOM（“文件物件模型”）是用與平台和語言無關的方式表示 XML 文檔的官方 W3C 標準。對於任何 Java 特定的模型，它是很好的對照。為了值得與 DOM 標準分開，Java 特定模型應該提供比 Java DOM 實現更優越的效能和／或易用性的優勢。 DOM 定義充分利用了 XML 文檔不同組件的介面和繼承性。這為開發人員帶來了將公用介面用於幾個不同類型組件的優勢，但是同時增加了 API 的複雜性。因為 DOM 是與語言無關的，所以介面不需要利用公用 Java 組件，例如，Collections 類。 本文涉及兩個 DOM 實現：Crimson 和 Xerces Java。Crimson 是基於 Sun Project X 解析器的 Apache 項目。它合并一個包含 DTD 支援的完整驗證解析器。可以通過 SAX2 介面訪問該解析器，並且 DOM 實現可以與其它 SAX2 解析器一起工作。Crimson 是在 Apache 許可證下發布的開放源碼。用於效能比較的版本是 Crimson 1.1.1（jar 檔案大小是 0.2MB），它包含有用於從文字檔的 DOM 構建的 SAX2 解析器。 另一個測試的 DOM 實現，即 Xerces Java 是另一個 Apache 項目。初始時，Xerces 基於 IBM Java 解析器（通常稱為 XML4J）。（當前還處於早期 beta 測試版的重新開發的 Xerces Java 2 將最終繼承它。目前的版本有時稱為 Xerces Java 1。）如同使用 Crimson 一樣，可以通過 SAX2 介面和 DOM 來訪問 Xerces 解析器。然而，Xerces 不提供將 Xerces DOM 與不同的 SAX2 解析器一起使用的任何方法。Xerces Java 包含對 DTD 和 XML Schema 的驗證支援（僅帶有對 Schema 支援的最小限制）。 Xerces Java 還支援 DOM 的延遲節點擴充方式（請參考本文中的延遲 Xerces 或 Xerces def.），其中文檔組件初始時是以壓縮格式表示的，僅當使用時才將它擴充成完整的 DOM 表示。這種方式的用意是允許更快的解析並降低記憶體的使用，尤其對於那些可能僅使用部分輸入文檔的應用程式。與 Crimson 類似，Xerces 是在 Apache 許可證下發布的開放源碼。用於效能比較的版本是 Xerces 1.4.2（jar 檔案大小是 1.8MB）。 JDOM JDOM 的目的是成為 Java 特定文檔模型，它簡化與 XML 的互動並且比使用 DOM 實現更快。由於是第一個 Java 特定模型，JDOM 一直得到大力推廣和促進。正在考慮通過“Java 規範請求 JSR-102”將它最終用作“Java 標準擴充”。雖然實際將採用的格式仍在開發中，還是對兩個 beta 測試版的 JDOM API 做了很大的更改，。從 2000 年初就已經開始了 JDOM 開發。 JDOM 與 DOM 主要有兩方面不同。首先，JDOM 僅使用具體類而不使用介面。這在某些方面簡化了 API，但是也限制了靈活性。第二，API 大量使用了 Collections 類，簡化了那些已經熟悉這些類的 Java 開發人員的使用。 JDOM 文檔聲明其目的是“使用 20%（或更少）的精力解決 80%（或更多）Java/XML 問題”（根據學習曲線假定為 20%）。JDOM 對於大多數 Java/XML 應用程式來說當然是有用的，並且大多數開發人員發現 API 比 DOM 容易理解得多。JDOM 還包括對程式行為的相當廣泛檢查以防止使用者做任何在 XML 中無意義的事。然而，它仍需要您充分理解 XML 以便做一些超出基本的工作（或者甚至理解某些情況下的錯誤）。這也許是比學習 DOM 或 JDOM 介面都更有意義的工作。 JDOM 自身不包含解析器。它通常使用 SAX2 解析器來解析和驗證輸入 XML 文檔（儘管它還可以將以前構造的 DOM 表示作為輸入）。它包含一些轉換器以將 JDOM 表示輸出成 SAX2 事件流、DOM 模型或 XML 常值文檔。JDOM 是在 Apache 許可證變體下發布的開放源碼。用於效能比較的版本是 JDOM Beta 0.7（jar 檔案大小是 0.1MB）它帶有用於從文字檔構建 JDOM 表示的 Crimson SAX2 解析器。 dom4j 雖然 dom4j 代表了完全獨立的開發結果，但最初，它是 JDOM 的一種智能分支。它合并了許多超出基本 XML 文檔表示的功能，包括整合的 XPath 支援、XML Schema 支援（當前為 alpha 格式）以及用於大文檔或流化文檔的基於事件的處理。它還提供了構建文檔表示的選項，它通過 dom4j API 和標準 DOM 介面具有並行訪問功能。從 2000 下半年開始，它就一直處於開發之中，保留了最近發行版之間的現有 API。 為支援所有這些功能，dom4j 使用介面和抽象基本類方法。dom4j 大量使用了 API 中的 Collections 類，但是在許多情況下，它還提供一些替代方法以允許更好的效能或更直接的編碼方法。直接好處是，雖然 dom4j 付出了更複雜的 API 的代價，但是它提供了比 JDOM 大得多的靈活性。 在添加靈活性、XPath 整合和對大文檔處理的目標時，dom4j 的目標與 JDOM 是一樣的：針對 Java 開發人員的易用性和直觀操作。它還致力於成為比 JDOM 更完整的解決方案，實現在本質上處理所有 Java/XML 問題的目標。在完成該目標時，它比 JDOM 更少強調防止不正確的應用程式行為。 dom4j 使用相同方法作為 JDOM 輸出，這依靠 SAX2 解析器輸入處理，依靠轉換器將輸出處理成 SAX2 事件流、DOM 模型或 XML 常值文檔。dom4j 是在 BSD 樣式許可證下發布的開放源碼，該許可證本質上等價於 Apache 樣式許可證。用於效能比較的版本是 dom4j 0.9（jar 檔案大小是 0.4MB），帶有用於從文字檔構建表示的受綁定 AElfred SAX2 解析器（由於 SAX2 選項設定，測試檔案之一無法由 dom4j 使用用於 JDOM 測試的同一 Crimson SAX2 解析器來處理）。 Electric XML Electric XML（EXML）是支援分散式運算的商業項目的附屬產物。它與目前為止討論的其它模型的不同之處在於，它只能適當地支援 XML 文檔的子集，它沒有為驗證提供任何支援並且有更嚴格的許可證。然而，EXML 的優勢是大小很小並提供了對 XPath 子集的直接支援，因為在最近幾篇文章中已經將它提升其它模型的替代模型，所以通過該比較使它成為一個引人注意的候選。 雖然 EXML 通過使用抽象的基本類方法取得了某些相同效果，但它在避免使用介面方面使用與 JDOM 類似的方法（主要區別是介面為擴充實現提供了更大的靈活性）。它與 JDOM 的不同之處還在於避免使用 Collections 類。該組合為其提供了非常簡單的 API，在許多方面類似於帶有附加 XPath 操作的 DOM API 簡化版本。 僅當空白與非空白常值內容鄰近時，EXML 才在文檔中保留空白，這就將 EXML 限制成 XML 文檔的一個子集。標準 XML 需要在讀取文檔時保留該空白，除非對文檔 DTD 可以確認有無空白無關緊要。對於事先已經知道空白無關緊要的許多 XML 應用程式來說，EXML 方法工作得很好，但是它防止對於期望保留空白的文檔（例如，產生由瀏覽器顯示或查看的文檔的應用程式）使用 EXML。（有關作者對於該主題的謙虛建議，請參閱副欄使用空白的目的。） 這種空白的刪除會對效能比較產生誤導效果 — 許多類型的測試範圍與文檔中的組件個數成比例，並且由 EXML 刪除的每個空白序列都是其它模型中的組件。EXML 包含在本文顯示的結果中，但是解釋效能差異時請記住這種影響。 EXML 使用整合的解析器依據文字文件構建文檔表示。除了通過文本方式外，它不提供從 DOM（或 SAX2）轉換或轉換成 SAX2（或 DOM）事件流的任何方式。EXML 是由 Mind Electric 在禁止將它嵌入某些類型的應用程式或庫的受限許可證下發布的開放源碼。用於效能比較的版本是 Electric XML 2.2（jar 檔案大小是 0.05MB）。 XML Pull Parser XML Pull Parser (XPP）是最近開發的，它示範了 XML 解析的不同方法。與 EXML 一樣，XPP 只能適當支援 XML 文檔的子集並且不提供驗證的任何支援。它同樣具有尺寸小的優勢。這種優勢再與拉回解析器方法結合，使它成為該比較中的良好替換項。 XPP 幾乎獨佔地使用介面，但是它僅使用所有類中的一小部分。和 EXML 一樣，XPP 避免使用 API 中的 Collections 類。總的來說，它是本文中最簡單的文檔模型 API。 將 XPP 限制成 XML 文檔子集的局限性是它不支援文檔中的實體、注釋或處理指示資訊。XPP 建立僅包含元素、屬性（包括“名稱空間”）和內容文本的文檔結構。這對於某些類型的應用程式來說是一種非常嚴格的限制。但是通常它對效能的影響比 EXML 空白處理對效能的影響小。在本文中我僅使用了一個與 XPP 不相容的測試檔案，並且在帶有注釋的圖表中顯示了 XPP 結果，該注釋不包含該檔案。 XPP 中的拉回解析器支援（本文中稱為 XPP 拉回）通過將解析實際上延遲到訪問文檔的一個組件時才進行，然後按照構造那個組件的需要對文檔進行解析。該技術想實現允許非常快速的文檔顯示或分類應用，尤其在需要轉寄或除去（而不是對文檔進行完全解析和處理）文檔時。該方法的使用是可選的，如果以非拉回型方式使用 XPP，它對整個文檔進行解析並且同時地構建完整的表示。 與 EXML 一樣，XPP 使用依據文字文件構建文檔表示的整合文法解析器，並且除了通過文本方式外，它不提供從 DOM（或 SAX2）轉換或轉換成 SAX2（或 DOM）事件流的任何方式。XPP 是具有 Apache 樣式許可證的開放原始碼。用於效能比較的版本是 PullParser 2.0.1 Beta 8（jar 檔案大小是 0.04MB）。 測試詳細資料 所顯示的計時結果是來自使用 Sun Microsystems Java version 1.3.1、Java HotSpot Client VM 1.3.1-b24 測試，這些軟體是運行在帶有 256MB RAM 的 Athlon 1GHz 系統上的 Redhat Linux 7.1 下。將這些測試的初始 JVM 和最大記憶體大小都設定成 128MB，我想將它表示為伺服器類型執行環境。 在使用初始預設 JVM 記憶體設定為 2MB 和最大記憶體為 64MB 啟動並執行測試中，帶有較大 jar 檔案大小（DOM、JDOM 和 dom4j）的模型的結果非常差，尤其在運行測試的平均時間中。這可能是由於記憶體受限執行的 HotSpot JVM 的無效操作引起的。 文檔模型中的兩種（XPP 和 EXML）支援直接將文檔輸入成“字串”或字元數組。該類型直接輸入不能代表實際應用程式，因此我在這些測試中避免使用它。對於輸入和輸出，我使用 Java 流封裝位元組以消除 I/O 對效能的影響，而保留了用於 XML 文檔輸入和輸出的應用程式在典型情況下使用的語言介面。 效能比較 本文中使用的效能比較基於對一組選中的 XML 文檔進行的解析和使用，這些文檔試圖代表較大範圍的應用程式： much_ado.xml，標記成 XML 的莎士比亞戲劇。沒有屬性並且是相當簡單的結構（202K 位元組）。 periodic.xml, XML 中的元素的周期表。一些屬性，也是相當簡單的（117K 位元組）。 soap1.xml，取自規範的樣本 SOAP 文檔。大量名稱空間和屬性（0.4K 位元組，每次測試需要重複 49 次）。 soap2.xml，SOAP 文檔格式中的值列表。大量名稱空間和屬性（134K 位元組）。 nt.xml，標記為 XML 的“新約”。沒有屬性並且非常簡單的結構，大量常值內容（1047K 位元組）。 xml.xml，XML 規範，不帶 DTD 引用，在內部定義所有實體。帶有大量混合內容的文本樣式標記，一些屬性（160K 位元組）。 關於測試平台的更多資訊，請參閱副欄測試詳細資料並查看參考資料以擷取用於測試的原始碼的連結。 除了非常小的 soap1.xml 文檔之外，所有評測時間都是指文檔的每次特定測試所經曆的時間。在 soap1.xml 的情況下，評測的時間是 49 個連續的文檔測試（總數為 20K 位元組文本的足夠副本數）。 測試架構在一個文檔上運行一個特定的測試多次（這裡顯示運行了 10 次），依此跟蹤該測試的最短時間和平均時間，然後繼續同一文檔上的下一個測試。完成對一個文檔的全部測試序列後，它對下一個文檔重複該過程。為防止文檔模型之間的互動，在執行每個測試架構時僅測試一個模型。 HotSpot 以及類似於動態最佳化 JVM 的計時基準程式是出了名的棘手的；測試序列中的小變化經常導致計時結果發生很大變化。我已經發現對於執行特定程式碼片段的平均時間時，確實如此；最短時間比較一致，正是我在這些結果中列出的值。可以參閱第一次測試（文檔構建時間）的平均和最短時間的比較。 文檔構建時間 文檔構建時間測試檢查解析文字文件和構造文檔表示所需的時間。出於比較目的，已經在圖表中包含了使用 Crimson 和 Xerces SAX2 解析的 SAX2 解析時間，因為大多數文檔模型（除了 EXML 和 XPP 外的所有文檔）使用 SAX2 解析事件流作為文檔構建過程的輸入。圖 1 描述了測試結果。 圖 1. 文檔構建時間 對於大多數測試文檔來說，XPP 拉回的構建時間太短以至於難以計算（因為在這種情況下，實際上沒有對該文檔進行解析），只顯示為非常短的 soap1.xml。對於該檔案，拉回解析器記憶體大小和相關的建立開銷使 XPP 顯得相對比較緩慢。這是因為測試程式為進行中解析的文檔的每個複本建立一個新的拉回解析器副本。在 soap1.xml 情況下，每次評測時間使用 49 個副本。分配與初始化這些解析器執行個體的開銷大於重複解析文本並構建文檔表示的大多數其它方法所需的時間。 XPP 的作者在一個電子郵件的討論中指出，在實際應用程式中，可以合用拉回解析器執行個體以重新使用。如果這樣做的話，soap1.xml 檔案的開銷將明顯降到忽略不計程度。對於更大的檔案，甚至不需要合用，拉回解析器建立開銷也可以變得忽略不計。 在本測試中，XPP（帶有完整解析），帶有延遲節點建立的 Xerces 和 dom4j 都顯示整體上的同等效能。延遲的 Xerces 對於較大的文檔尤其出色，但是對於較小的文檔的開銷較高 — 甚至比常規 Xerces DOM 高很多。在第一次使用文檔的一部分時，延遲節點建立方法的開銷也較高，這會降低快速解析的優勢。 對於較小的 soap1.xml 檔案，所有格式（SAX2 解析、常規 DOM 和延遲 DOM）的 Xerces 的顯得開銷較高。對於該檔案 XPP（完全解析）尤其出色，對於 soap1.xml，EXML 甚至超過基於 SAX2 的模型。雖然 EXML 具有廢棄單獨的空白內容的優勢，但是總體上，它是本測試中最差的。 文檔遍曆時間 文檔遍曆時間測試檢查遍曆構造的文檔表示所需的時間，按文檔順序遍曆每個元素、屬性和常值內容段。它試圖表示文檔模型介面的效能，這對於從進行過解析的文檔中重複訪問資訊的應用程式來說可能很重要。總體上，遍曆時間比解析時間快得多。對於只對解析過的文檔單次遍曆的應用程式，解析時間將比遍曆時間更重要。圖 2 顯示了結果。 圖 2. 文檔遍曆時間 在本測試中，XPP 的效能大大超過了其餘的測試對象。Xerces DOM 所花費的時間大約是 XPP 的兩倍。雖然 EXML 具有廢棄文檔中單獨的空白內容的優勢，但是，EXML 花費的時間幾乎是 XPP 的三倍。dom4j 在這張圖中處於中間位置。 使用 XPP 拉回時，直到訪問文檔表示時才真正發生對文檔文本的解析。這導致第一次遍曆文檔表示時的開銷非常大（表中未顯示）。如果以後訪問整個文檔表示，則當使用拉回解析方法時，XPP 顯示效能的淨損失。對於拉回解析器來說，前兩個測試所需的總時間比使用 XPP 的常規解析長（長 20% 到 100%，這取決於文檔）。但是，當還未完全訪問進行中解析的文檔時，拉回解析器方法仍然具有可觀的效能優勢。 帶有延遲節點建立的 Xerces 顯示了相似的行為，第一次訪問文檔表示時導致效能下降（圖中未顯示）。但是，在 Xerces 情況下，節點建立開銷大約與解析期間常規 DOM 建立的效能差值相同。對於較大的文檔來說，用 Xerces 延遲的前兩次測試所需的總時間大致與使用帶常規 DOM 構建的 Xerces 所用的時間相同。如果在非常大的文檔（可能 10KB 或更大）上使用 Xerces，則延遲的節點建立似乎是一個好選擇。 文檔修改時間 這個測試檢查系統地修改構造文檔表示所需的時間，其結果在圖 3 中顯示。它遍曆表示，刪除所有單獨的空白內容並且用新添加的元素封裝每個非空白內容字串。它還向包含非空白內容的原始文檔的每個元素中添加一個屬性。該測試試圖表示經過一定範圍文檔修改後文檔模型的效能。如遍曆時間一樣，修改時間比解析時間短很多。因此，對於僅單次遍曆每個解析過的文檔的應用程式來說，解析時間將更重要。 圖 3. 文檔修改時間 這次測試中 EXML 處於領先地位，但是由於在解析期間它總是廢棄單獨的空白內容，它才比其它模型具有效能上的優勢。這意味著在測試期間沒有要從 EXML 表示中進行刪除的內容。 在修改效能方面，XPP 僅次於 EXML，並且與 EXML 不同，XPP 測試包含刪除。Xerces DOM 和 dom4j 接近地處於中間位置，JDOM 和 Crimson DOM 模型的效能仍是最差。 文本產生時間 這個測試檢查將文檔表示輸出成文本 XML 文檔所需的時間；結果顯示在圖 4 中。對於不專門使用 XML 文檔的任何應用程式，該步驟似乎是整體效能的一個重要部分，特別是因為將文檔輸出為文本所需的時間總體接近於對文檔輸入進行解析所需的時間。為使這些時間具有直接的可比性，該測試使用原始文檔，而沒有使用由前面的測試所產生的已修改文檔。 圖 4. 文本產生時間 文本產生時間測試表明各模型之間的差別小於前面測試中各項的差別，Xerces DOM 效能最好，但領先不多，JDOM 效能最差。EXML 的效能優於 JDOM，但是這同樣是由於 EXML 廢棄空白內容。 許多模型提供了控制文本輸出格式的選項，並且一些選項似乎影響文本產生時間。這個測試只使用每個模型的最基本的輸出格式，因此結果只顯示預設效能而不顯示最好的可能效能。 文檔記憶體大小 這個測試檢查用於文檔表示的記憶體空間。這對於使用大文檔或同時使用多個較小文檔的開發人員來說，意義尤為重要。圖 5 顯示這個測試的結果。 圖 5. 文檔記憶體大小 記憶體大小結果與計時測試不同，因為小的 soap1.xml 檔案顯示的值表示檔案的單個副本而不表示在計時評測中使用的 49 個副本。在大多數模型中，用於簡要文檔的記憶體太小以至於無法在圖的刻度上顯示。 除了 XPP 拉回（直到訪問它時才真正構建文檔表示）之外，與一些計時測試中顯示的差別相比，記憶體大小測試中模型之間的差別相對較小。延遲的 Xerces 具有最緊湊的表示（當第一次訪問表示時將它擴充成基本 Xerces 大小），緊接著是 dom4j。雖然 EXML 廢棄包含在其它模型中的空白內容，但是它仍具有最不緊湊的表示。 因為即使最緊湊的模型也要佔用大約原始文檔文字大小（以位元組計）四倍的空間，所以對於大文檔來說，所有模型似乎都需要太多的記憶體。通過提供使用部分文檔表示的方法，XPP 拉回和 dom4j 為非常大的文檔提供了最好的支援。XPP 拉回通過僅構建實際被訪問的表示部分完成該任務，而 dom4j 包含對基於事件處理的支援，使得一次只構建或處理文檔的一部分。 Java 序列化 這些測試評測文檔表示的 Java 序列化的時間和輸出大小。這主要涉及那些使用 Java RMI（“遠程方法調用”）在 Java 程式之間傳送表示的應用程式（包括 EJB (Enterprise JavaBean) 應用程式）起作用。在這些測試中，僅包含了那些支援 Java 序列化的模型。下列三張圖顯示了該測試的結果。 圖 6. 序列化輸出時間 圖 7. 序列化輸入時間 圖 8. 序列化文檔大小 dom4j 顯示了輸出（產生序列化的格式）和輸入（從序列化的格式重新構建文檔）的最好的序列化效能，而 Xerces DOM 顯示了最差的效能。EXML 所花費的時間接近 dom4j，但是 EXML 還是具有在表示中使用較少數量對象的優勢，因為它廢棄空白內容。 如果將文檔輸出成文本然後進行解析以重新構建文檔，而不是使用 Java 序列化，則所有效能 — 時間和大小 — 都會好得多。這裡的問題是作為大量唯一的小對象的 XML 文檔表示的結構。Java 序列化無法有效處理這種類型的結構，這導致時間和輸出大小的開銷都很高。 可以設計比文本表示小且比文本輸入和輸出快的文檔序列化格式，但是只能通過繞過 Java 序列化來完成。（我有一個項目實現 XML 文檔的這種定製的序列化，在我公司的 Web 網站上可以找到其開放源碼，請參閱參考資料。） 結束語 不同的 Java XML 文檔模型各有所長，但是從效能觀點來看，有些模型具有明顯的優勢。 在大多數方面，XPP 效能處於領先地位。儘管 XPP 是一種新模型，但是對於不需要驗證、實體、處理指示資訊或注釋的中介軟體類型應用程式來說，它是非常好的選擇。它尤其適用於作為瀏覽器小應用程式或在記憶體受限的環境下啟動並執行應用程式。 雖然 dom4j 沒有與 XPP 同等的速度，但是，它確實提供了具備更標準化的優越效能和功能更全的實現，包括對 SAX2、DOM 甚至 XPath 的內建支援。雖然 Xerces DOM（帶有延遲的節點建立）對於小檔案和 Java 序列化效能不佳，但是在大多數評測時仍然出色。對於常規 XML 處理，dom4j 和 Xerces DOM 都是很好的選擇，對它們的選擇取決於您認為是特定於 Java 的特性更重要還是跨語言的相容性更重要。 JDOM 和 Crimson DOM 在效能測試時一直表現不佳。在小文檔情況下還值得考慮使用 Crimson DOM，而 Xerces 表現很差。雖然 JDOM 的開發人員已經說明他們期望在正式發行版前專註效能問題，但是從效能觀點來看，它確實沒有值得推薦之處。然而，如果不進行 API 的重新構建，JDOM 可能難以達到與其它模型匹配的效能。 使用空白的目的 XML 規範通常需要保留空白，但是許多 XML 應用程式使用僅為可讀性而保留空白的格式。對於這些應用程式，EXML 廢棄隔離空白的方法起了作用。 這些效能中使用的大多數文檔屬於“為可讀性而保留的空白”類別。這些文檔被格式化成便於人們查看的形式，一行最多一個元素。結果，無關的空白內容字串數實際上超過了文檔中的元素數量。這大大增加了每一步處理的不必要開銷。 支援修剪輸入上這種類型空白的選項將有助於提高帶有可忽略的空白的應用程式的所有文檔模型的效能（除了 EXML 之外）。只要修剪是一個選項，它就不會影響需要完全保留空白的應用程式。解析器層級的支援將更好，因為解析器必須逐一處理輸入字元。總之，這種類型的選項將非常有助於許多 XML 應用程式。 EXML 非常小（以 jar 檔案大小為單位）並且在一些效能測試中表現良好。雖然 EXML 具有刪除單獨空白內容的優勢，但是在效能方面不如 XPP。除非您需要 EXML 支援而 XPP 缺少的一種特性，否則在記憶體受限的環境下，XPP 可能是更好的選擇。 雖然 dom4j 效能最好，但是，當前沒有一種模型能為 Java 序列化提供良好效能。如果需要在程式之間傳遞文檔，通常的最佳選擇是將文檔寫成文本然後進行解析以重新構建表示。將來，定製序列化格式可能提供一個更好的選擇。 後續內容... 我已經涵蓋了一些文檔模型的基本特性，並且顯示了幾種類型文檔操作的效能評測。請記住，雖然，效能只是選擇文檔模型的一個因素。對於大多數開發人員，可用性至少與效能一樣重要，並且這些模型使用不同的 API 都可能有喜歡這個而不喜歡那個的理由。 在後續文章中將集中研究可用性，其中我將比較用於完成這些不同模型中相同操作的樣本代碼。請檢查本比較的第二部分。當您等待時，可以通過下面的論壇中的連結提出您對本文的評論和問題與大家共用。 參考資料 參加關於本文的論壇。 如果您需要背景知識，請嘗試 developerWorks的教程 XML Java 編程、 理解 SAX 和 理解 DOM 。 從下載頁面下載用於本文的測試程式和文檔模型庫。 在測試程式的首頁上查看更新的測試和測試結果。 擷取作者關於 XML Serial (XMLS) encoding 工作的詳細資料作為 Java 序列化的替代項。 研究或下載本文中討論的 Java XML 文檔模型： Xerces Java Crimson JDOM dom4j Electric XML（EXML） XML Pull Parser（XPP） IBM WebSphere Application Server 包含基於 Xerces Java 的 XML4J 解析器。可在 WAS Advanced edition 3.0 online documentation 中找到關於產品 XML 支援的 how-to 資訊。 關於作者 Dennis Sosnoski（dms@sosnoski.com）是西雅圖地區 Java 諮詢公司 Sosnoski Software Solutions, Inc. 的建立者和首席顧問。他具有 30 多年的專業軟體開發經驗，最近幾年，他集中研究伺服器方 Java 技術，包括 servlet、Enterprise JavaBeans 和 XML。他已經多次示範了 Java 效能問題和常規伺服器端的 Java 技術，他還是 Seattle Java-XML SIG 的主席。 到頁首