⑴ 廢棄fastjson！大型項目遷移至Gson保姆級攻略
為何要放棄fastjson？
fastjson頻繁暴露安全漏洞，導致公司內部需要頻繁升級版本，以防止安全問題。相比之下，Gson和Jackson漏洞數量少，高危漏洞也較少，這是公司替換框架的主要原因。
性能對比
Fastjson在序列化單對象時速度最快，但Gson在序列化大對象時性能優勢明顯。Jackson在序列化大Json對象時性能最好。
使用Gson替換Fastjson
這里總結了兩種json框架常用的方法，幫助快速上手Gson，無縫切換！
常見問題排雷
總結
文章主要為需要將項目遷移到Gson框架的同學准備。文章中提到了遷移框架的必要性評估，包括框架兼容性、性能差異和遷移耗費的工時等問題。希望對讀者有所幫助。
參考
⑵ 問題復盤｜在使用 gson 時，數字被自動轉為 double 類型
在使用Gson進行數據轉換時，遇到數字自動轉為double類型的問題。將一個JsonObject轉換為Map後，數字全部變為double形式，年齡2變為2.0，身高98.2正常顯示，但登記時間顯示為1.694533284627E12。面對此問題，我首先嘗試通過搜索引擎尋找解決方案。發現Gson默認將number類型數據解析為double類型，並指出此問題在版本2.8.9中已修復。我查看自己使用的Gson版本為2.8.6，低於2.8.9，且存在相同問題。問題定位後，解決方法較為直接：升級Gson版本至2.8.9，並在創建Gson對象時手動設置數字類型轉換策略。完成這些步驟後，問題得到解決。總結，此問題並非首次出現，也難以避免再次發生，簡單記錄，等待有緣人參考。
⑶ Gson，FastJson，org.JSON到底哪一個效率更高，速度更快
FastJson效率最高，是阿里巴巴開源 的Json處理工具包，包括「序列化」和「反序列化」兩部分，它具備如下特徵：
速度最快，測試表明，fastjson具有極快的性能，超越任其他的Java Json parser。包括自稱最快的JackJson；
功能強大，完全支持Java Bean、集合、Map、日期、Enum，支持范型，支持自省；無依賴，能夠直接運行在Java SE 5.0以上版本；支持Android；
⑷ 漸進式實現Gson(1) - toJson
近期，我對小傅哥的Spring和Mybatis系列教程產生了濃厚的興趣，特別是他解析大型項目的技巧，這激發了我對編程的熱情。為了提升自己，我決定從Gson源碼開始學習。
為何選擇Gson？
我使用IDEA創建了一個新的Maven項目，並配置了pom.xml，以便進行單元測試和日誌記錄。
基礎類型
首先，我從簡單的基礎類型開始，包括整數、字元串和布爾類型。
Gson的使用第一步是創建實例，將類轉換為JSON字元串。這里涉及到toJson方法的設計。
toJson方法有幾個同名版本，通常只需傳遞對象。最終調用的toJson方法是不返回值的，而我們所調用的toJson方法返回字元串。這表明結果存儲在StringWriter對象中。
JsonWriter是基於Writer介面進行封裝的，負責基本的JSON字元串寫入操作。
為什麼最後要由TypeAdapter來寫？因為JsonWriter只負責基本操作，不同類有不同的處理方式。因此，定義抽象類TypeAdapter來提取類的共同邏輯，然後由具體類實現寫入方法。
為什麼Gson這里要用列表存儲，而不是哈希表？雖然哈希表在獲取效率上更高，但列表在這里更合適。
TypeAdapter實現
TypeAdapter使用工廠模式創建，因為它會受到Gson配置的影響。這與myBatis的SqlSessionFactory和SqlSession類似。用戶不是直接調用SqlSession連接資料庫，而是根據SqlSessionFactory收集的配置來創建SqlSession。最後，補充JsonWriter的方法。
這里沒有太多難點，除了字元串處理，需要考慮特殊符號的情況。
最後，進行測試。
數組
同樣，先寫單元測試。
與基礎類型相比，數組的處理更為復雜。
JsonWriter需要考慮作用域，增加相關邏輯。
創建棧數組，默認先添加空文件狀態。如果之後寫入值，則通過beforeValue和replaceTop來修改狀態。如果是數組，則寫入開括弧，添加空數組狀態，增加值則修改有非空。每次添加值，就加逗號，直到數組寫入結束，加上關括弧。
進行測試。
POJO類
終於到了POJO類的情況。
在Gson中添加相應的TypeAdapter。
與之前相比，POJO的處理要復雜得多。看一下工廠類的create方法。
它是處理繼承Object的類，結合之前處理整數和布爾值的情況，就能明白為什麼Gson類要用列表存儲TypeAdapterFactory，因為要處理的類和TypeAdapter之間不是一一對應的關系。例如，之前處理整數和布爾值時，不僅要考慮int和boolean，還要考慮Integer和Boolean包裝類，需要用同一的TypeAdapter處理，但後者又是繼承Object，所以處理對象與TypeAdapter是多對一的關系，因此不能用哈希表處理。這一點也體現出工業級工具庫與Demo的不同，前者的主要流程代碼不一定多，但需要考慮大量的細節，應對不同的邊界條件。
接著的邏輯沒什麼，就是取出POJO類的field信息，封裝，然後用JsonWriter寫入。至於為什麼代碼看起來比較復雜，因為源碼要考慮對象不少復雜情況，如jvm內部、泛型處理等。
最後增加JsonWriter的邏輯。
進行測試。
源碼：gitee.com/Dominguito/sm...
切換至toJson分支查看。