JSON庫的性能比較

這篇文章主要講解了“JSON庫的性能比較”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“JSON庫的性能比較”吧！

Java 中哪個 JSON 庫的解析速度是最快的?

JSON 已經成為當前服務器與 WEB  應用之間數據傳輸的公認標準，不過正如許多我們所習以為常的事情一樣，你會覺得這是理所當然的便不再深入思考了。我們很少會去想用到的這些 JSON  庫到底有什么不同，但事實上它們的確是不太一樣的。因此，我們運行了一個基準測試來對常用的幾個 JSON  庫進行了測試，看看在解析不同大小的文件時哪個庫的速度是最快的。下面我會把結果分享給大家。

JSON 通常用于傳輸及解析大文件。這對運行在 Hadoop 或者是 Spark  集群上的數據處理程序而言是個很常見的場景。在給定的文件大小下，你可以看到不同庫之間的解析速度存在著明顯的差別。

高吞吐量的情況下，會頻繁地傳輸并解析小文件，因此一開始的時候可能性能的差距并不明顯。但如果你需要在非常高負載下頻繁地解析大量的小文件，差距就開始增大了。微服務及分布式架構經常會使用  JSON 來傳輸此類文件，因為這已經是 WEB API 的事實標準。

不是所有的 JSON 庫都叫” 特侖蘇”。如何根據使用場景才選擇正確的庫是相當重要的。希望這個基準測試能夠對你有所幫助。

JSON 庫

JSON.simple vs GSON vs Jackson vs JSONP

我們選擇了四個主流的 JSON 庫來進行基準測試：JSON.simple， GSON, Jackson 以及 JSONP。在 Java 中進行 JSON  解析通常都會用到這幾個庫，選擇它們的原因是它們在 Github 項目中的亮相頻率很高。

下面便是我們所測試的 JSON 庫：

• Yidong Fang 的 JSON.simple 。JSON.simple 是一個 JSON 編解碼的 Java  工具庫。它旨在打造一個輕量簡單且高性能的工具庫。

• Google 的 GSON。GSON 這個 Java 庫能夠在 Java 對象和 JSON 間進行相互轉換。同時它還提供了對 Java  泛型的完整支持，而且還不需要你在類上面添加注解。無需添加注解使用起來則更為便捷，同時在無法修改源代碼的情況下這還是一個必要的先決條件。

• FasterXML 的 Jackson 項目。Jackson 是一個數據處理的工具套件，它的亮點是流式的 JSON 解析器及生成器。它是專為 Java  設計的，同時也能處理其它非 JSON 的編碼。從我們在 Github 中的統計來看，它應該是***的 JSON 解析器。

• Oracle 的 JSONP。JSONP (JSON Processing) 是 JSON 處理的一套 Java API, 從名字來看它就是用來生成及解析  JSON 串的。這是 JSR353 規范的一個開源實現。

基準測試

我們同時使用大文件和小文件對這些庫進行了基準測試。隨著文件大小的不同，處理這些文本所需要的系統資源也會隨之上升。

這個基準測試主要關注兩個關鍵場景：大文件下 (190MB) 的解析速度與小文件(1KB)下的解析速度。大文件取自這里。小文件是從這里隨機生成的。

不管是大文件還是小文件，我們都會用同一個庫重復運行 10 次。對于每一個大文件，我們都會用同一個庫來分別運行 10  次。而對于小文件，在單個庫的單次運行中會重復執行 10000 次。在小文件測試的各次迭代中，文件內容都不會駐留在內存里，測試所運行的機器是 AWS 的  c3.large 實例。

大文件的完整測試結果如下，我對小文件的結果求了個平均值。

大文件結果

結果相差甚大!Jackson 與 JSON.simple 領跑了這輪測試，整體來看 Jackson 又要略優于  JSON.simple。從測試運行的平均結果來看，Jackson 與 JSON.simple 在大文件上的表現要優秀一些，而 JSONP  排名第三落后甚遠，GSON 更是遙遙墊底。

我們再把結果換算成百分比看下。平均來看 Jackson 要勝出一籌。下面是結果的百分比數據，可以從兩個維度來進行比較：

不同庫之間的性能差別著實不小。

結論：Jackson 以略微優勢勝出。JSON.simple 緊隨其后，而剩下兩個庫則遠遠落后。

小文件結果

上表記錄的是對每個文件解析 10 次的平均時間，總的平均時間見下方。各個庫在小文件測試中奪冠的次數如下：

• GSON - 14

• JSONP - 5

• Jackson -1

• JSON.simple - 0

這個結果貌似很有說服力。然而，從所有文件的平均結果來看，GSON 這個冠軍還是當之無愧的，JSON.simple 和 JSONP  的二三名之爭應該沒什么懸念。Jackson 這輪卻是墊底了。盡管 JSON.simple 沒有在任何文件上奪得***，但總體來看它的解析速度卻是排名第二位的。而  JSONP 盡管在許多文件上都拿到了冠軍，但平均來看卻只拿到了第三名的成績。

還有一個值得注意的是，盡管 Jackson 是這輪最慢的庫，但是它在所有文件中的表現都非常一致，其它三個庫雖然偶然會比 Jackson  快很多，但在另一些文件上的解析速度卻是旗鼓相當甚至更差。

我們再把這些數字轉換成百分比看看，還是同樣的兩個維度：

和大文件測試相比，這次的差距相對要小一些，但也還是不容忽視的。

結論：很不幸的是，JSON.simple 又以微弱的劣勢與冠軍失之交臂，這輪 GSON 勝。JSONP 仍是千年老三而這回 Jackson  則趕了個晚集。

總結

解析速度并非衡量一個 JSON  庫的唯一指標，但它的確非常重要。通過運行這次基準測試，我們發現沒有一個庫能在所有文件上擊敗對手。大文件中表現優秀的卻在小文件上栽了根頭，反之亦然。

• 如果要從解析速度來看選擇哪個庫的話還得取決于你的使用場景。

• 如果你的應用經常會處理大的 JSON 文件，那么 Jackson 應該是你的菜。GSON 在大文件上表現得相當吃力。

• 如果你主要是處理小文件請求，比如某個微服務或者分布式架構的初始化，那么 GSON 當是***。Jackson 在小文件上的表現則不如人意。

• 如果這兩種文件你都經常會處理到，那么在兩輪表現中都位居第二的 JSON.simple 對此類場景則更為適合。在不同的文件大小上 Jackson 和  GSON 的表現都不太好。

除非不考慮解析速度，不然 JSONP 完全沒有什么值得稱道的。它在大文件和小文件上的表現與其它庫相比都很糟糕。所幸的是，Java 9 很快便會有原生的  JSON 實現了，相信 JSONP 將來的表現仍然值得期待。

感謝各位的閱讀，以上就是“JSON庫的性能比較”的內容了，經過本文的學習后，相信大家對JSON庫的性能比較這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！