《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 dwz.cn/ztVmUvBI 「甘明」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

知乎上有人提问:fastjson这么快,为啥老外还是热衷 jackson? 下面是甘明的回答,从各个方面分析了这个问题:

哈哈哈,我来回答这个问题!

因为我实在是对这两个库太熟悉了。

1、你写个bean,然后属性里分别有包含_(下划线开头、#开头)之类的属性,序列化为json时,出现属性丢失,那么自然你也无法反序列化回来。

这个问题,1.2.14版本以后已经改正。

2、翻阅fastjson的源码,你会发现有很多写死的代码,比如:针对spring之类的框架的各种处理,都是用classload判断是否存在这种类名。

这是什么意思呢?

意思就是如果你用spring的那种思想,自己写了个类似的功能,因为你这个项目里没有spring的那个类,那么用起来就有一堆bug;当然不仅限于这些,还有很多,比如ASM字节码织入部分,看源码的话,能发现的缺点数不胜数。

3、其解析json主要是用的String类substring这个方法,所以解析起来非常“快”,因为申请内存次数很少。

但是因为jdk1.7之前substring的实现并没有new一个新对象,在使用的时候,如果解析的json非常多,稍不注意就会出现内存泄漏(比如一个40K的json,你在对象里引用了里边的一个key,即使这个key只有2字节,也会导致这40K的json无法被垃圾回收器回收),这也是“快”带来的负面效果。

而且这还不算,在jdk1.7以上版本对string的substring方法做了改写,改成了重新new一个string的方式,于是这个“快”的优势也不存在了。

img

最后,fastjson就是一个代码质量较差的国产类库,用很多投机取巧的的做法去实现所谓的“快”,而失去了原本应该兼容的java特性,对json标准遵循也不严格,自然很难在国际上流行。

json从发明到现在非常流行,并不是因为json快的原因(比json快且小巧的格式和类库一大把),而是因为json和web结合的时候更易于使用,对开发人员易于理解。

很多人拿fastjson和jackson比,就像拿非智能机和iphone比待机时间,其功能性不一样,jackson的很多功能fastjson并没有实现,所以这种对比也不客观。

fastjson之所以没在国际上流行起来,最主要的原因应该是开发者的思路全放到“快”上去了,而偏离了“标准”及功能性,质量也不够好,有点“舍本逐末”的味道。

当然在目前的环境下,国产软件能踏实的心态做好开源的不多,fastjson团队能这么快的反馈并修正问题,这种精神还是值得称赞的。希望国内的技术从业者能更重视“技术的原始需求”。

你觉得会是什么原因?欢迎在留言区讨论。

文章目录
  1. 1. 1、你写个bean,然后属性里分别有包含_(下划线开头、#开头)之类的属性,序列化为json时,出现属性丢失,那么自然你也无法反序列化回来。
  2. 2. 2、翻阅fastjson的源码,你会发现有很多写死的代码,比如:针对spring之类的框架的各种处理,都是用classload判断是否存在这种类名。
  3. 3. 3、其解析json主要是用的String类substring这个方法,所以解析起来非常“快”,因为申请内存次数很少。
  4. 4. 最后,fastjson就是一个代码质量较差的国产类库,用很多投机取巧的的做法去实现所谓的“快”,而失去了原本应该兼容的java特性,对json标准遵循也不严格,自然很难在国际上流行。