阅读全文

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

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

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

---

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

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的方式，于是这个“快”的优势也不存在了。

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

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

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

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

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

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