看圖說話，FastJson 并沒有那么流行！-有解無憂

作者：咔咔侃技術

來源：www.toutiao.com/i6815906868183958027

一、FastJson為何

首先抄錄一段來自官網的介紹：FastJson是阿里巴巴的開源JSON決議庫，它可以決議JSON格式的字串，支持將Java Bean序列化為JSON字串，也可以從JSON字串反序列化到JavaBean，

FastJson是Java程式員常用到的類別庫之一，相信點開這個頁面的你，也肯定是程式員朋友，正如其名，“快”是其主要賣點，

二、真的很快嗎？

沒有調研就沒有發言權，本著“追求真理”的初心，來一輪簡單的測驗，對比物件選擇應用最廣泛的Jackson和Google出品的Gson，

測驗環境選擇JDK 8，AMD 3700X，3200MHZ記憶體，簡化實驗，只測驗簡單物件和復雜物件的String轉物件、物件轉String，呼叫1千萬次的對比結果如下(時間單位是毫秒)：

從測驗結果看，FastJson確實是最快的，但僅比Jackson快20%左右，Google的Gson是最慢的，差距較大，讀到這里，是不是覺得選擇FastJson肯定沒錯啊！

如果面試官問為什么選擇FastJson？因為快！這一個理由就可以把他頂回去了，

這里的調查研究并不是很充分，沒有對記憶體占用、大檔案的測驗，

在現代應用程式中，即使最慢的Gson，也是滿足需求的；決議檔案速度的快慢，并不能作為選型的唯一標準，可能連主要標準都算不上，對IO優化，并行處理等優化措施，比選用一個更快的庫更有效，

三、FastJson并沒有那么流行

然而，FastJson并沒有那么流行，有一個最直觀的資料，那就是在Maven的中的參考量，和Jackson和Gson不在一個數量級，和Jackson強大的家族更沒法比，

難道我用了一個假的流行的國產類別庫？在知乎看到了一篇帖子，討論為什么外國友人不喜歡FastJson，

結論就是FastJson是個代碼質量不高的國產類別庫，完全顛覆了我的認知，因為在我的專案中，是經常使用FastJson的，并沒有出現什么Bug，而且這段評論是在2016年寫的，

抱著懷疑的態度，打開FastJson的地址，看到大家提的Issues，竟然有1283個未解決的Issues，紅框標識出來的，我自己拿去研究下，因為我看到下面還有人提了一樣的問題，

測驗代碼如下：

 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();
  }

果然，在采用了最新版本的類別庫后，如問題描述的，還是有例外，于是就看到了如下的源代碼：

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);
}

這段代碼有嚴重的邏輯錯誤，這樣錯誤的格式，例如：

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

或者

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

也能轉換成功，而一些正確的格式，例如：

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

卻轉換失敗，

結合網友的點評，我本人也覺得FastJson并沒有那么優秀，另一些深入的點評，例如ASM，我的理解并不深，就不做測驗了，

四、棄坑fastjson

在我負責的專案中，因為Spring Boot相關的框架中，應用了Jackson，本著“最少依賴”的原則，json決議應用了Jackson，但是很多同事的代碼中，也用了Gson和Fastjson，當然，是沒有嚴格規范要求的結果，

通過今天的一個小小研究，Jackson的流行，是有著內在的原因的，在我們以后的專案中，主推Jackson，逐漸的淘汰Fastjson，

推薦去我的博客閱讀更多：

1.Java JVM、集合、多執行緒、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、后端、架構、阿里巴巴等大廠最新面試題

覺得不錯，別忘了點贊+轉發哦！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/43146.html

標籤：Java

上一篇：一鍵生成資料庫檔案，堪稱資料庫界的Swagger，有點厲害！

下一篇：一文了解Zookeeper