看圖說話，F(xiàn)astJson 并沒有那么流行！

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

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

二、真的很快嗎？

沒有調(diào)研就沒有發(fā)言權(quán)，本著“追求真理”的初心，來一輪簡(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千萬次的對(duì)比結(jié)果如下(時(shí)間單位是毫秒)：

從測(cè)試結(jié)果看，F(xiàn)astJson確實(shí)是最快的，但僅比Jackson快20%左右，Google的Gson是最慢的，差距較大。讀到這里，是不是覺得選擇FastJson肯定沒錯(cuò)啊！

如果面試官問為什么選擇FastJson？因?yàn)榭?！這一個(gè)理由就可以把他頂回去了。

這里的調(diào)查研究并不是很充分，沒有對(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并沒有那么流行

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

難道我用了一個(gè)假的流行的國(guó)產(chǎn)類庫(kù)？在知乎看到了一篇帖子，討論為什么外國(guó)友人不喜歡FastJson。

結(jié)論就是FastJson是個(gè)代碼質(zhì)量不高的國(guó)產(chǎn)類庫(kù)。完全顛覆了我的認(rèn)知，因?yàn)樵谖业捻?xiàng)目中，是經(jīng)常使用FastJson的，并沒有出現(xiàn)什么Bug，而且這段評(píng)論是在2016年寫的。

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

測(cè)試代碼如下：

?try?{
??????String?time?=?"1970-01-01?00:00:00";
??????com.alibaba.fastjson.JSONObject?jsonObject?=?new?com.alibaba.fastjson.JSONObject();
??????jsonObject.put("time",?time);

??????Timestamp?timestamp?=?jsonObject.getTimestamp("time");
??????System.out.println("time:"?+?timestamp);
??}?catch?(Exception?e)?{
??????e.printStackTrace();
??}

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

if?(strVal.endsWith(".000000000"))?{
????strVal?=?strVal.substring(0,?strVal.length()?-?10);
}?else?if?(strVal.endsWith(".000000"))?{
????strVal?=?strVal.substring(0,?strVal.length()?-?7);
}

if?(strVal.length()?==?29?&&?strVal.charAt(4)?==?'-'?&&?strVal.charAt(7)?==?'-'?&&?strVal.charAt(10)?==?'?'?&&?strVal.charAt(13)?==?':'?&&?strVal.charAt(16)?==?':'?&&?strVal.charAt(19)?==?'.')?{
????int?year?=?num(strVal.charAt(0),?strVal.charAt(1),?strVal.charAt(2),?strVal.charAt(3));
????int?month?=?num(strVal.charAt(5),?strVal.charAt(6));
????int?day?=?num(strVal.charAt(8),?strVal.charAt(9));
????int?hour?=?num(strVal.charAt(11),?strVal.charAt(12));
????int?minute?=?num(strVal.charAt(14),?strVal.charAt(15));
????int?second?=?num(strVal.charAt(17),?strVal.charAt(18));
????int?nanos?=?num(strVal.charAt(20),?strVal.charAt(21),?strVal.charAt(22),?strVal.charAt(23),?strVal.charAt(24),?strVal.charAt(25),?strVal.charAt(26),?strVal.charAt(27),?strVal.charAt(28));
??return?new?Timestamp(year?-?1900,?month?-?1,?day,?hour,?minute,?second,?nanos);
}

這段代碼有嚴(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)，我本人也覺得FastJson并沒有那么優(yōu)秀，另一些深入的點(diǎn)評(píng)，例如ASM，我的理解并不深，就不做測(cè)試了。

四、棄坑fastjson

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

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