Json 已成為當前服務器與 web 應用之間數據傳輸的公認標准。
微服務及分布式架構經常會使用 Json 來傳輸此類文件，因為這已經是 webAPI 的事實標准。
不過正如許多我們習以為常的事情一樣，你會覺得這是理所當然的便不再深入比較。
我們很少會去想用到的這些 Json 庫到底有什么不同，但事實上它們的確是不太一樣的。
因此，我們團隊來對常用的三個 Json 庫運行測試，看看在解析不同大小文件時哪個庫的速度最快。
在給定的文件大小下，你可以看到不同庫之間的解析速度存在着明顯的差別。
高吞吐量的情況下，會頻繁傳輸解析小文件，因此一開始的時候可能性能的差距並不明顯。
但如果你需要在非常高負載下頻繁地解析大量的小文件，差距就開始增大了。
不是所有的 Json 庫都叫"特侖蘇"。如何根據使用場景才選擇正確的庫是相當重要的。
1. 選取的開源 Json 庫
選擇三個個主流的Json 庫來進行基准測試：Jackson, Json .simple,GSON
-
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 的編碼。
2. 相對條件下的基准測試
我們同時使用大文件和小文件對這些庫進行了基准測試。隨着文件大小的不同，處理這些文本所需要的系統資源也會隨之上升。
這個基准測試主要關注兩個關鍵場景：
1.大文件下(190MB)的解析速度與小文件（1KB）下的解析速度。大文件取自這里：https://github.com/zeMirco/sf-city-lots-Json 。
2.小文件是從這里隨機生成的：http://www.Json -generator.com/。
不管是大文件還是小文件，我們都會用同一個庫重復運行10次。
對於每一個大文件，我們都會用同一個庫來分別運行10 次。
而對於小文件，在單個庫的單次運行中會重復執行10000 次。
在小文件測試的各次迭代中，文件內容都不會駐留在內存里。
大文件結果
Jackson 與 Json .simple 領跑了這輪測試，整體來看 Jackson 又要略優於 Json .simple。
從測試運行的平均結果來看，Jackson 與 Json .simple 在大文件上的表現要優秀。
而 JsonNP 排名第三落后甚遠，Gson 更是遙遙墊底。
小文件結果
上表記錄的是對每個文件解析10次的平均時間，總的平均時間見下方。各個庫在小文件測試中奪冠的次數如下：
- GSON - 14
- Json P - 5
- Jackson -1
- Json .simple - 0
Gson 這個冠軍還是當之無愧的，Json.simple 第二也沒什么懸念。Jackson這輪卻是墊底了。
盡管 Json.simple 沒有在任何文件上奪得第一，但總體來看它的解析速度卻是排名第二位的。
還有一個值得注意的是，盡管 Jackson 是這輪最慢的庫，但是它在所有文件中的表現都非常一致。
其它三個庫雖然偶然會比 Jackson 快很多，但在另一些文件上的解析速度卻是旗鼓相當甚至更差。
3. 最后總結
解析速度並非衡量一個Json 庫的唯一指標，但它的確非常重要。
通過運行這次基准測試，我們發現沒有一個庫能在所有文件上擊敗對手。
大文件中表現優秀的卻在小文件上栽了根頭，反之亦然。
如果要從解析速度來看選擇哪個庫的話還得取決於你的使用場景。
- 如果你的應用經常會處理大的 Json 文件，那么 Jackson 應該是你的菜。Gson 在大文件上表現得相當吃力。
- 如果你主要是處理小文件請求，比如某個微服務或者分布式架構的初始化，那么 Gson 當是首選。Jackson 在小文件上的表現則不如人意。
- 如果這兩種文件你都經常會處理到，那么在兩輪表現中都位居第二的 Json.simple 對此類場景則更為適合。
如果你對 Json 庫的解析速度比較敏感的話。
大文件選 Jackson，小文件選GSON，兩者則Json .simple。