泰州网站建设推广/app推广一手单

点击上方“Java基基”，选择“设为星标”

做积极的人，而不是积极废人！

每天 14:00 更新文章，每天掉亿点点头发...

源码精品专栏

• 原创 | Java 2021 超神之路，很肝~
  

• 中文详细注释的开源项目
  

• RPC 框架 Dubbo 源码解析

• 网络应用框架 Netty 源码解析

• 消息中间件 RocketMQ 源码解析
  

• 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析

• 作业调度中间件 Elastic-Job 源码解析

• 分布式事务中间件 TCC-Transaction 源码解析

• Eureka 和 Hystrix 源码解析

• Java 并发源码

来源：toutiao.com/i6815906868183958027

• 一、FastJson为何

• 二、真的很快吗？

• 三、FastJson并没有那么流行

• 四、弃坑fastjson

大家好，我是基基。

最近和朋友们正在肝一个单体的开源项目：https://github.com/YunaiV/ruoyi-vue-pro

上周末把项目中使用到 FastJSON 的地方，全部替换成 Jackson，涉及到的点有：

1. 使用 JSON 的地方，使用封装的 JsonUtil 替换

2. SpringMVC 的消息转换器，替换成 Jackson 实现的

3. Spring Data Redis 的对象转换器，替换成 Jackson 实现的

4. MyBatis 使用到 JSON TypeHandler 的地方，替换成 Jackson 实现的

5. 和时间序列化相关的，需要稍微注意下，具体可以看看 spring.jackson 配置项

因为 FastJSON 存在一些非标的行为，所以替换之后，还是要回归下~

另外，没有考虑使用 GSON 的原因，一方面它最后维护时间是 2019 年，一方面一些开源库内嵌使用了 Jackson 的特性

记得 Star 关注下噢，胖友们的支持，真的很重要！

一、FastJson为何

首先抄录一段来自官网的介绍：FastJson是阿里巴巴的开源JSON解析库，它可以解析JSON格式的字符串，支持将Java Bean序列化为JSON字符串，也可以从JSON字符串反序列化到JavaBean。

FastJson是Java程序员常用到的类库之一，相信点开这个页面的你，也肯定是程序员朋友。正如其名，“快”是其主要卖点。

推荐下自己做的 Spring Boot 的实战项目：

https://github.com/YunaiV/ruoyi-vue-pro

二、真的很快吗？

没有调研就没有发言权，本着“追求真理”的初心，来一轮简单的测试。对比对象选择应用最广泛的Jackson和Google出品的Gson。测试环境选择JDK 8，AMD 3700X，3200MHZ内存。简化实验，只测试简单对象和复杂对象的String转对象、对象转String，调用1千万次的对比结果如下(时间单位是毫秒)：

从测试结果看，FastJson确实是最快的，但仅比Jackson快20%左右，Google的Gson是最慢的，差距较大。读到这里，是不是觉得选择FastJson肯定没错啊！如果面试官问为什么选择FastJson？因为快！这一个理由就可以把他顶回去了。

这里的调查研究并不是很充分，没有对内存占用、大文档的测试。

在现代应用程序中，即使最慢的Gson，也是满足需求的；解析文档速度的快慢，并不能作为选型的唯一标准，可能连主要标准都算不上。对IO优化，并行处理等优化措施，比选用一个更快的库更有效。

推荐下自己做的 Spring Cloud 的实战项目：

https://github.com/YunaiV/onemall

三、FastJson并没有那么流行

然而，FastJson并没有那么流行，有一个最直观的数据，那就是在Maven的中的引用量，和Jackson和Gson不在一个数量级，和Jackson强大的家族更没法比。

难道我用了一个假的流行的国产类库？在知乎看到了一篇帖子，讨论为什么外国友人不喜欢FastJson。结论就是FastJson是个代码质量不高的国产类库。完全颠覆了我的认知，因为在我的项目中，是经常使用FastJson的，并没有出现什么Bug，而且这段评论是在2016年写的。

抱着怀疑的态度，打开FastJson的地址，看到大家提的Issues。竟然有1283个未解决的Issues。红框标识出来的，我自己拿去研究下，因为我看到下面还有人提了一样的问题。

测试代码如下：

果然，在采用了最新版本的类库后，如问题描述的，还是有异常。于是就看到了如下的源代码：

这段代码有严重的逻辑错误，这样错误的格式，例如：

“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

在我负责的项目中，因为SpringBoot相关的框架中，应用了Jackson，本着“最少依赖”的原则，json解析应用了Jackson。但是很多同事的代码中，也用了Gson和Fastjson，当然，是没有严格规范要求的结果。

通过今天的一个小小研究，Jackson的流行，是有着内在的原因的。在我们以后的项目中，主推Jackson，逐渐的淘汰Fastjson。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 6W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）