每天 11 點(diǎn)更新文章，餓了點(diǎn)外賣，點(diǎn)擊 ??《無(wú)門檻外賣優(yōu)惠券，每天免費(fèi)領(lǐng)！》

• 一、FastJson為何
• 二、真的很快嗎？
• 三、FastJson并沒(méi)有那么流行
• 四、棄坑fastjson

最近艿艿和朋友們正在肝一個(gè)單體的開(kāi)源項(xiàng)目：https://github.com/YunaiV/ruoyi-vue-pro

上周末把項(xiàng)目中使用到 FastJSON 的地方，全部替換成 Jackson，涉及到的點(diǎn)有：

1. 使用 JSON 的地方，使用封裝的 JsonUtil 替換
2. SpringMVC 的消息轉(zhuǎn)換器，替換成 Jackson 實(shí)現(xiàn)的
3. Spring Data Redis 的對(duì)象轉(zhuǎn)換器，替換成 Jackson 實(shí)現(xiàn)的
4. MyBatis 使用到 JSON TypeHandler 的地方，替換成 Jackson 實(shí)現(xiàn)的
5. 和時(shí)間序列化相關(guān)的，需要稍微注意下，具體可以看看 spring.jackson 配置項(xiàng)

因?yàn)?FastJSON 存在一些非標(biāo)的行為，所以替換之后，還是要回歸下~

另外，沒(méi)有考慮使用 GSON 的原因，一方面它最后維護(hù)時(shí)間是 2019 年，一方面一些開(kāi)源庫(kù)內(nèi)嵌使用了 Jackson 的特性

記得 Star 關(guān)注下噢，胖友們的支持，真的很重要！

一、FastJson為何

首先抄錄一段來(lái)自官網(wǎng)的介紹：FastJson是阿里巴巴的開(kāi)源JSON解析庫(kù)，它可以解析JSON格式的字符串，支持將Java Bean序列化為JSON字符串，也可以從JSON字符串反序列化到JavaBean。

FastJson是Java程序員常用到的類庫(kù)之一，相信點(diǎn)開(kāi)這個(gè)頁(yè)面的你，也肯定是程序員朋友。正如其名，“快”是其主要賣點(diǎn)。

二、真的很快嗎？

沒(méi)有調(diào)研就沒(méi)有發(fā)言權(quán)，本著“追求真理”的初心，來(lái)一輪簡(jiǎn)單的測(cè)試。對(duì)比對(duì)象選擇應(yīng)用最廣泛的Jackson和Google出品的Gson。測(cè)試環(huán)境選擇JDK 8，AMD 3700X，3200MHZ內(nèi)存。簡(jiǎn)化實(shí)驗(yàn)，只測(cè)試簡(jiǎn)單對(duì)象和復(fù)雜對(duì)象的String轉(zhuǎn)對(duì)象、對(duì)象轉(zhuǎn)String，調(diào)用1千萬(wàn)次的對(duì)比結(jié)果如下(時(shí)間單位是毫秒)：

從測(cè)試結(jié)果看，F(xiàn)astJson確實(shí)是最快的，但僅比Jackson快20%左右，Google的Gson是最慢的，差距較大。讀到這里，是不是覺(jué)得選擇FastJson肯定沒(méi)錯(cuò)啊！如果面試官問(wèn)為什么選擇FastJson？因?yàn)榭欤∵@一個(gè)理由就可以把他頂回去了。

這里的調(diào)查研究并不是很充分，沒(méi)有對(duì)內(nèi)存占用、大文檔的測(cè)試。

在現(xiàn)代應(yīng)用程序中，即使最慢的Gson，也是滿足需求的；解析文檔速度的快慢，并不能作為選型的唯一標(biāo)準(zhǔn)，可能連主要標(biāo)準(zhǔn)都算不上。對(duì)IO優(yōu)化，并行處理等優(yōu)化措施，比選用一個(gè)更快的庫(kù)更有效。

三、FastJson并沒(méi)有那么流行

然而，F(xiàn)astJson并沒(méi)有那么流行，有一個(gè)最直觀的數(shù)據(jù)，那就是在Maven的中的引用量，和Jackson和Gson不在一個(gè)數(shù)量級(jí)，和Jackson強(qiáng)大的家族更沒(méi)法比。

難道我用了一個(gè)假的流行的國(guó)產(chǎn)類庫(kù)？在知乎看到了一篇帖子，討論為什么外國(guó)友人不喜歡FastJson。結(jié)論就是FastJson是個(gè)代碼質(zhì)量不高的國(guó)產(chǎn)類庫(kù)。完全顛覆了我的認(rèn)知，因?yàn)樵谖业捻?xiàng)目中，是經(jīng)常使用FastJson的，并沒(méi)有出現(xiàn)什么Bug，而且這段評(píng)論是在2016年寫(xiě)的。

抱著懷疑的態(tài)度，打開(kāi)FastJson的地址，看到大家提的Issues。竟然有1283個(gè)未解決的Issues。紅框標(biāo)識(shí)出來(lái)的，我自己拿去研究下，因?yàn)槲铱吹较旅孢€有人提了一樣的問(wèn)題。

測(cè)試代碼如下：

果然，在采用了最新版本的類庫(kù)后，如問(wèn)題描述的，還是有異常。于是就看到了如下的源代碼：

這段代碼有嚴(yán)重的邏輯錯(cuò)誤，這樣錯(cuò)誤的格式，例如：

“1970-01-01 00:00:00.000000000.000000000”

或者

“1970-01-01 00:00:00.000000000.000000”

也能轉(zhuǎn)換成功，而一些正確的格式，例如：

““1970-01-01 00:00:00”，““1970-01-01 00:00:00.000”

卻轉(zhuǎn)換失敗。

結(jié)合知乎上網(wǎng)友的點(diǎn)評(píng)，我本人也覺(jué)得FastJson并沒(méi)有那么優(yōu)秀，另一些深入的點(diǎn)評(píng)，例如ASM，我的理解并不深，就不做測(cè)試了。

四、棄坑fastjson

在我負(fù)責(zé)的項(xiàng)目中，因?yàn)镾pringBoot相關(guān)的框架中，應(yīng)用了Jackson，本著“最少依賴”的原則，json解析應(yīng)用了Jackson。但是很多同事的代碼中，也用了Gson和Fastjson，當(dāng)然，是沒(méi)有嚴(yán)格規(guī)范要求的結(jié)果。

通過(guò)今天的一個(gè)小小研究，Jackson的流行，是有著內(nèi)在的原因的。在我們以后的項(xiàng)目中，主推Jackson，逐漸的淘汰Fastjson。

看完文章，餓了點(diǎn)外賣，點(diǎn)擊 ??《無(wú)門檻外賣優(yōu)惠券，每天免費(fèi)領(lǐng)！》

若覺(jué)得文章對(duì)你有幫助，隨手轉(zhuǎn)發(fā)分享，也是我們繼續(xù)更新的動(dòng)力。