這篇文章主要講解了“FastJson快嗎”,文中的講解內(nèi)容簡單清晰,易于學(xué)習(xí)與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“FastJson快嗎”吧!
我們提供的服務(wù)有:網(wǎng)站建設(shè)、成都網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、陳倉ssl等。為上1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù),是有科學(xué)管理、有技術(shù)的陳倉網(wǎng)站制作公司
首先抄錄一段來自官網(wǎng)的介紹:FastJson是阿里巴巴的開源JSON解析庫,它可以解析JSON格式的字符串,支持將Java Bean序列化為JSON字符串,也可以從JSON字符串反序列化到JavaBean。
FastJson是Java程序員常用到的類庫之一,相信點(diǎn)開這個頁面的你,也肯定是程序員朋友。正如其名,“快”是其主要賣點(diǎn)。
沒有調(diào)研就沒有發(fā)言權(quán),本著“追求真理”的初心,來一輪簡單的測試。對比對象選擇應(yīng)用最廣泛的Jackson和Google出品的Gson。
測試環(huán)境選擇JDK 8,AMD 3700X,3200MHZ內(nèi)存。簡化實(shí)驗(yàn),只測試簡單對象和復(fù)雜對象的String轉(zhuǎn)對象、對象轉(zhuǎn)String,調(diào)用1千萬次的對比結(jié)果如下(時間單位是毫秒):
從測試結(jié)果看,F(xiàn)astJson確實(shí)是最快的,但僅比Jackson快20%左右,Google的Gson是最慢的,差距較大。讀到這里,是不是覺得選擇FastJson肯定沒錯??!
如果面試官問為什么選擇FastJson?因?yàn)榭?!這一個理由就可以把他頂回去了。
這里的調(diào)查研究并不是很充分,沒有對內(nèi)存占用、大文檔的測試。
在現(xiàn)代應(yīng)用程序中,即使最慢的Gson,也是滿足需求的;解析文檔速度的快慢,并不能作為選型的唯一標(biāo)準(zhǔn),可能連主要標(biāo)準(zhǔn)都算不上。對IO優(yōu)化,并行處理等優(yōu)化措施,比選用一個更快的庫更有效。
然而,F(xiàn)astJson并沒有那么流行,有一個最直觀的數(shù)據(jù),那就是在Maven的中的引用量,和Jackson和Gson不在一個數(shù)量級,和Jackson強(qiáng)大的家族更沒法比。
難道我用了一個假的流行的國產(chǎn)類庫?在知乎看到了一篇帖子,討論為什么外國友人不喜歡FastJson。
結(jié)論就是FastJson是個代碼質(zhì)量不高的國產(chǎn)類庫。完全顛覆了我的認(rèn)知,因?yàn)樵谖业捻?xiàng)目中,是經(jīng)常使用FastJson的,并沒有出現(xiàn)什么Bug,而且這段評論是在2016年寫的。
抱著懷疑的態(tài)度,打開FastJson的地址,看到大家提的Issues。竟然有1283個未解決的Issues。紅框標(biāo)識出來的,我自己拿去研究下,因?yàn)槲铱吹较旅孢€有人提了一樣的問題。
測試代碼如下:
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); }
這段代碼有嚴(yán)重的邏輯錯誤,這樣錯誤的格式,例如:
“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)評,我本人也覺得FastJson并沒有那么優(yōu)秀,另一些深入的點(diǎn)評,例如ASM,我的理解并不深,就不做測試了。
在我負(fù)責(zé)的項(xiàng)目中,因?yàn)镾pring Boot相關(guān)的框架中,應(yīng)用了Jackson,本著“最少依賴”的原則,json解析應(yīng)用了Jackson。但是很多同事的代碼中,也用了Gson和Fastjson,當(dāng)然,是沒有嚴(yán)格規(guī)范要求的結(jié)果。
通過今天的一個小小研究,Jackson的流行,是有著內(nèi)在的原因的。在我們以后的項(xiàng)目中,主推Jackson,逐漸的淘汰Fastjson。
感謝各位的閱讀,以上就是“FastJson快嗎”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對FastJson快嗎這一問題有了更深刻的體會,具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關(guān)知識點(diǎn)的文章,歡迎關(guān)注!
網(wǎng)站名稱:FastJson快嗎
轉(zhuǎn)載來于:http://jinyejixie.com/article46/pdcgeg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供手機(jī)網(wǎng)站建設(shè)、網(wǎng)站排名、關(guān)鍵詞優(yōu)化、云服務(wù)器、商城網(wǎng)站、網(wǎng)站改版
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)