[[431913]]

【51CTO.com快譯】如今，JSON已經是公認的、服務器與Web應用之間數據傳輸的API標準。它通過各種代碼庫，可以在Hadoop或Spark集群中，方便那些基于微服務和分布式架構的數據處理應用程序，傳輸和解析不同類型與大小的文件。不過，并非所有的JSON庫都會執行相同的操作方式。在高吞吐量的環境中，一旦出現了快速、連續、大量的小文件，它們的解析速度就會出現巨大的差別。

可見，為自己的應用環境選擇合適的代碼庫，往往是至關重要的。為此，我準備了一系列基準性的測試，將和您討論目前四種最為流行的Java JSON庫--JSON.simple、GSON、Jackson、以及JSONP，在解析不同文件大小時的速度，以方便您能夠做出明智的選擇。

四大JSON庫簡介

由于這四種代碼庫都時常被廣泛地用于Java環境的JSON處理過程，因此我們根據它們在Github項目中的受歡迎程度，進行逐一介紹：

• Yidong Fang的JSON.simple：是一個可用于編、解碼的JSON文本類Java工具包。它旨在成為一個簡單、輕量級、且能夠高速運行的代碼庫。
• Google的GSON：是一個能夠實現Java對象與JSON格式相互轉換的Java代碼庫。由于提供了對于Java泛型的完全支持，因此您既不需要對自己的類進行注釋，又能夠簡化對于特權源代碼的訪問。
• FasterXML的Jackson項目：是一組帶有流式JSON解析器和生成器庫的處理工具。雖然它是針對Java設計的，但是它可以處理其他非JSON類的編碼。根據Github使用情況的調查結果，它目前是最受歡迎的JSON解析器之一。
• Oracle的JSONP：JSON Processing是以Java API的形式，通過消費(consuming)和生成(producing)流式JSON文本，來提供對于JSON的處理。它屬于開源參考JSR353的實現。

基準：2017

我們根據不同文件大小的處理需求，在不同的庫環境中，測試性地解析了不同大小的文件?？偟恼f來，我們將基準測試分為兩個關鍵場景：

• 從https://github.com/zeMirco/sf-city-lots-json處獲取190 MB的大文件，并測試其解析速度。
• 從http://www.json-generator.com/處隨機生成1 KB的小文件，并測試其解析速度。

無論是大文件，還是小文件，我們讓每個庫都對每個文件運行10次。其中，對于大文件而言，每個庫的每一次運行時，都會進行10次迭代;而對于小文件，它們會每次運行10,000次迭代。而且在小文件的測試中，我們不會在迭代的間隙中，將文件保留在內存里，而是直接在AWS上的c3.large實例中運行測試。

下圖完整地顯示了大文件的解析結果。為了節省空間，我對小文件的解析結果進行了平均。如果您想查看擴展的結果，請參見--https://docs.google.com/spreadsheets/d/1iOSAkqRwGGbLHRkcKSyHwpOWYdSrkuQKyUIZ6ef7N-I/edit?usp=sharing。而如果您想查看小文件或庫的源代碼，則請參見--https://github.com/terencetaih/aws-speed。

大文件結果：2017

從上表中，我們可以看出Jackson或JSON.simple在處理大文件上用時最少，而且Jackson在總體上會領先于JSON.simple。通過查看所有測試的平均運行結果可知，Jackson和JSON.simple遙遙領先，JSONP名列第三，GSON排在最后。下面，讓我們以Jackson為基準，用百分比來表示各個JSON庫的解析速度：

小文件結果：2017

上表顯示了每個文件被運行10次的平均值，最下面一行是總的平均值。各個庫所獲得的文件數量分別為：

• GSON - 14
• JSONP - 5
• Jackson – 1
• JSON.simple – 0

由所有文件的平均測試結果可知：

• GSON是其中的贏家。
• 盡管在任何單個文件上都不是最快的，但是JSON.simple在總體上名列第二。
• 盡管在少數文件上能夠達到最快，但是JSONP在總體上仍排名第三。
• 雖然Jackson在所有文件解析中都表現得非常一致，但是與其他三個庫相比，Jackson的運行速度是最慢的。

讓我們同樣以GSON為基準，用百分比來表示各個JSON庫的解析速度：

結論：2017

在選擇JSON庫時，解析速度雖然并非唯一的考慮因素，但它的確是一個重要的參考指標。在運行上述基準測試時，我們發現沒有一個庫可以在所有文件大小、以及所有解析速度上，同時能夠擊敗其他庫。在大文件解析上表現最好的庫，反而對小文件的表現并不佳，反之亦然。

因此，我們可以參照如下環境特征，根據各自的解析速度優勢，選擇合適的JSON庫。

• 如果您的環境需要經?；蛑饕幚泶笮偷腏SON文件，那么Jackson可以成為您的首選庫，而GSON在處理此類大文件時會非常費勁。
• 如果您的環境主要處理大量的小型JSON請求，例如需要在微服務、或分布式架構中進行各種設置的話，那么GSON可以成為您的首選庫，而Jackson在處理小文件方面會比較費勁。
• 如果您的環境不得不經常處理大小不同的文件，那么由于JSON.simple在上述兩類測試中都排在第二位，因此可以成為適用于可變環境的實用工具(畢竟Jackson和GSON在不同文件大小上的表現各有利弊)。

JSONP在任何情況下，與其他三種JSON庫相比，對于各種文件的解析速度性能都比較差，因此不太值得推薦。當然，據報道Java 9正在獲得JSON的原生實現，那么我們可以預見到它將會在參考實現方面，有所改進。

基準：2021

下面，我們將使用最新的JSON庫，并在Java 11上再次運行相同的基準測試?？傮w而言，它們會在性能上，比我們之前運行的基準測試，出現顯著的提高。

大文件結果：2021

如上表所示，本輪基準測試的贏家是GSON，JSONP緊隨其后，接著是Jackson，最后才是JSON.simple。那么，讓我們以GSON為基準，用百分比來表示各個JSON庫的解析速度：

小文件結果：2021

上表顯示了小文件的測試結果，Gson以明顯的速度優勢，再次擊敗了其他三個JSON庫，蟬聯冠軍。JSONP緊隨其后，接著是JSON.simple，最后才是Jackson。

由表可知，Gson處理這些文件的速度比第二名快了近200多毫秒。

結論：2021

通過上述兩大類測試與比較，我們不難發現，無論是Java本身，還是各個JSON庫，都在速度上提升了不少。其中，GSON的進步最為明顯，并且能夠最終在大文件和小文件，兩類基準測試中脫穎而出。

原文標題：The UltimateJSONLibrary:JSON.simple vs. GSON vs. Jackson vs.JSONP，作者：Nick Andrews

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】