精品伊人久久大香线蕉,开心久久婷婷综合中文字幕,杏田冲梨,人妻无码aⅴ不卡中文字幕

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。如果你對這次的基準測試有什么疑問請在下方留言。