Java 下的 JSON庫效能比較：JSON.simple vs. GSON vs. Jackson vs. JSONP

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

JSON通常用於傳輸及解析大檔案。這對執行在Hadoop或者是Spark叢集上的資料處理程式而言是個很常見的場景。在給定的檔案大小下，你可以看到不同庫之間的解析速度存在著明顯的差別。

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

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

JSON.simple vs GSON vs Jackson vs JSONP

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

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

• Yidong Fang的JSON.simple(https://github.com/fangyidong/json-simple)。JSON.simple是一個JSON編解碼的Java工具庫。它旨在打造一個輕量簡單且高效能的工具庫。
• Google的GSON(https://github.com/google/gson)。GSON這個Java庫能夠在Java物件和JSON間進行相互轉換。同時它還提供了對Java泛型的完整支援，而且還不需要你在類上面新增註解。無需新增註解使用起來則更為便捷，同時在無法修改原始碼的情況下這還是一個必要的先決條件。
• FasterXML的Jackson專案（https://github.com/FasterXML/jackson）。Jackson是一個資料處理的工具套件，它的亮點是流式的JSON解析器及生成器。它是專為Java設計的，同時也能處理其它非JSON的編碼。從我們在Github中的統計來看，它應該是最流行的JSON解析器。
• Oracle的JSONP(https://jsonp.java.net/)。JSONP (JSON Processing)是JSON處理的一套Java API,從名字來看它就是用來生成及解析JSON串的。這是JSR353規範的一個開源實現。

基準測試

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

這個基準測試主要關注兩個關鍵場景：大檔案下(190MB)的解析速度與小檔案（1KB）下的解析速度。大檔案取自這裡：https://github.com/zeMirco/sf-city-lots-json。小檔案是從這裡隨機生成的：http://www.json-generator.com/。

不管是大檔案還是小檔案，我們都會用同一個庫重複執行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庫的解析速度比較敏感的話，大檔案選Jackson，小檔案選GSON，兩者則JSON.simple。如果你對這次的基準測試有什麼疑問請在下方留言。