作者：?甘明

來(lái)源：https://dwz.cn/ztVmUvBI

知乎上有人提問(wèn)：fastjson這么快，為啥老外還是熱衷 jackson? 下面是甘明的回答，從各個(gè)方面分析了這個(gè)問(wèn)題：

哈哈哈，我來(lái)回答這個(gè)問(wèn)題！

因?yàn)槲覍?shí)在是對(duì)這兩個(gè)庫(kù)太熟悉了。

1、你寫個(gè)bean，然后屬性里分別有包含_（下劃線開頭、#開頭）之類的屬性，序列化為json時(shí)，出現(xiàn)屬性丟失，那么自然你也無(wú)法反序列化回來(lái)。

這個(gè)問(wèn)題，1.2.14版本以后已經(jīng)改正。

2、翻閱fastjson的源碼，你會(huì)發(fā)現(xiàn)有很多寫死的代碼，比如：針對(duì)spring之類的框架的各種處理，都是用classload判斷是否存在這種類名。

這是什么意思呢？

意思就是如果你用spring的那種思想，自己寫了個(gè)類似的功能，因?yàn)槟氵@個(gè)項(xiàng)目里沒有spring的那個(gè)類，那么用起來(lái)就有一堆bug；當(dāng)然不僅限于這些，還有很多，比如ASM字節(jié)碼織入部分，看源碼的話，能發(fā)現(xiàn)的缺點(diǎn)數(shù)不勝數(shù)。

3、其解析json主要是用的String類substring這個(gè)方法，所以解析起來(lái)非?！翱臁?#xff0c;因?yàn)樯暾?qǐng)內(nèi)存次數(shù)很少。

但是因?yàn)閖dk1.7之前substring的實(shí)現(xiàn)并沒有new一個(gè)新對(duì)象，在使用的時(shí)候，如果解析的json非常多，稍不注意就會(huì)出現(xiàn)內(nèi)存泄漏（比如一個(gè)40K的json，你在對(duì)象里引用了里邊的一個(gè)key，即使這個(gè)key只有2字節(jié)，也會(huì)導(dǎo)致這40K的json無(wú)法被垃圾回收器回收），這也是“快”帶來(lái)的負(fù)面效果。

而且這還不算，在jdk1.7以上版本對(duì)string的substring方法做了改寫，改成了重新new一個(gè)string的方式，于是這個(gè)“快”的優(yōu)勢(shì)也不存在了。

最后，fastjson就是一個(gè)代碼質(zhì)量較差的國(guó)產(chǎn)類庫(kù)，用很多投機(jī)取巧的的做法去實(shí)現(xiàn)所謂的“快”，而失去了原本應(yīng)該兼容的java特性，對(duì)json標(biāo)準(zhǔn)遵循也不嚴(yán)格，自然很難在國(guó)際上流行。?

json從發(fā)明到現(xiàn)在非常流行，并不是因?yàn)閖son快的原因（比json快且小巧的格式和類庫(kù)一大把），而是因?yàn)閖son和web結(jié)合的時(shí)候更易于使用，對(duì)開發(fā)人員易于理解。

很多人拿fastjson和jackson比，就像拿非智能機(jī)和iphone比待機(jī)時(shí)間，其功能性不一樣，jackson的很多功能fastjson并沒有實(shí)現(xiàn)，所以這種對(duì)比也不客觀。

fastjson之所以沒在國(guó)際上流行起來(lái)，最主要的原因應(yīng)該是開發(fā)者的思路全放到“快”上去了，而偏離了“標(biāo)準(zhǔn)”及功能性，質(zhì)量也不夠好，有點(diǎn)“舍本逐末”的味道。

當(dāng)然在目前的環(huán)境下，國(guó)產(chǎn)軟件能踏實(shí)的心態(tài)做好開源的不多，fastjson團(tuán)隊(duì)能這么快的反饋并修正問(wèn)題，這種精神還是值得稱贊的。希望國(guó)內(nèi)的技術(shù)從業(yè)者能更重視“技術(shù)的原始需求”。

你覺得會(huì)是什么原因？歡迎在留言區(qū)討論。

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的知乎：fastjson这么快，为啥老外还是热衷 jackson?的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。