转载

Fastjson到了说再见的时候了

生命太短暂，不要去做一些根本没有人想要的东西。本文已被 https://www.yourbatman.cn 收录，里面一并有Spring技术栈、MyBatis、JVM、中间件等小而美的专栏供以免费学习。关注公众号【 BAT的乌托邦 】逐个击破，深入掌握，拒绝浅尝辄止。

Fastjson到了说再见的时候了

前言

各位小伙伴大家好，我是A哥。停更1个月后回归啦，今天咱们聊聊一个比较有意思的话题：是否真的需要跟Fastjson说再见了？

我的态度

我在CSDN写过好些篇关于JSON的文章，特别是2020年专门写了一个付费专栏： 享学Jackson
Fastjson到了说再见的时候了这个专栏“销量”在我心目中还凑合，4个月“卖出”200份的样子（虽不值一提，但我很满足了:smile:），小小的一个JSON库而已，热度可见一斑。专栏里不可避免的提到了Jackson和Fastjson的比较，我本人一直持中立态度，主要原因有二：

两者都很流行（国内Fastjson流行度甚至超过Jackson），因此平时开发中我 两者都用 （需要随大流嘛）
国产开源软件是需要被支持的，即使现在还存在差距（联想下 最初的 国产手机和苹果手机的差距，再看看现在呢？）

当然，本文不一样了，必须得加点料。态度中立并不代表没有偏向：很明显我偏向于使用Jackson作为你的唯一 JSON库。

从本文起，我将把CSDN里该付费专栏 全部内容 搬到公众号，免费助你轻松拥抱世界上最好的JSON库：Jackson。

市面上并无成体系介绍Jackson的教程（官网都木有），独此一家哦。当然喽，这必将损伤到我的CSDN专栏售卖权益（小钱也是钱嘛:smile:），所以希望你关注公众号，关注此专栏，然后学到手我就觉得值了

2020-05-30阿里云应急响应中心监测到Fastjson爆发新的反序列化远程代码执行漏洞，黑客利用漏洞，可绕过autoType限制，直接远程执行任意命令攻击服务器， 风险极大 （话外音：此bug必须Fix）。幸运的是，官方的响应速度非常快：

还记得上一次Fastjson 高级别风险 安全漏洞是什么时候吗？是的，它就发生在2019-09-04，两次相距着实不远，不满你说我还记忆犹新呢，我司安全部门发的邮件还能找到:smile:。

当然，之前也有些漏洞问题，但关注度不如这两次。主要是这两次时间相近，危险级别非常高影响面很大，所以社区反应较为强烈

这两次“相邻”的安全漏洞着实把Fastjson推到了风口浪尖，吃瓜群众一波接一波，一时间 “弃用Fastjson，拥抱Jackson/Gson” 的声音不绝于耳。这很容易理解，因为谁都不情愿时不时收到公司安全部门的这种邮件：

针对此漏洞，虽说咱们Fix起来步骤简单：升级Fastjson的版本，然后重启应用。看起来毫不费力，实则是个大坑。你是否曾想过这个问题：倘若有上百个、几百个Java应用呢？且不谈你操作上的时间和人力成本有多高，单单管理起来的工作量也不容小觑。所以如果你是技术Leader，胸中的怒火释放一下是在情理之中的。

相信很少有部门/团队把Spring Boot应用做成 Jar包分离 的形式的吧~因此大概率都需要经过升版本 -> 提交代码 -> 合代码 -> 上pre -> 上线 -> 验证等步骤，so还是比较麻烦的

你为何用Fastjson？

这个问题你可以问自己，也可以问身边的同事。汇总一下就是答案，这才是来自用户最真实的声音嘛。我针对此也简单“调查”过，把我听到的了解到的汇总为如下三点：

API简单（static方法直接使用），上手快，对开发者友好
阿里巴巴出品，背靠大厂值得信赖.
社区相对活跃，维护升级有保障

容我猜猜，这3个理由大概率命中了你心中所想吧:smile:？有大厂做背书自然能给产品加分，但自身优秀才是硬道理。虽然原因有三点，但我认为让很多人决定去使用它、赞它的最最最主要原因其实就一点： API简单，static方法直接调用对开发者友好 。

我感觉对于大多数Java Coder（特别对于初学者）来说，使用时会有这样的一种情节在里面：静态方法的逼格比实例方法高。而实际上不应该是这样子的，初学者（初/中级选手）热爱使用静态方法，而高手在设计一个库/框架时应在静态方法+实例方法间运用自如。一味地、过多地使用静态方法只会让你的的思维倾向于 面向过程 ，而非更好的利用Java 面向对象 的特性，因此高下立判。

没有孰优孰劣，适合的才是最好的

发现了没，使用Fastjson的原因中，我们至始至终都没有提到性能高/速度快等字眼，但这却是Fastjson最最最为核心的特性，可谓是它能立足于众多JSON库中、“脱颖而出”的立身之本。岂不怪哉，我们使用它竟不是因为它最核心的特性有多好，那这是为何呢？

你为何仍在用Fastjson？

原因可以说出5678种，总而言之言而总之，你不（敢）切换的原因或许只有一个：Fastjson的静态方法调用用着省心；最重要的是， 对其它JSON库（如Jackson/Gson）并不熟悉 不敢切换。

我认为 害怕来自于未知

不可否认Jackson/Gson的使用门槛的确比Fastjson高那么一丢丢，但这绝不是你拒绝去使用它的理由。受Fastjson这“连续”两次高危漏洞影响，A哥更加坚定了把Jackson当作唯一 JSON库的决心，甚至在团队内 严令禁止使用Fastjson 。大家统一了语言/工具，更能提高生产力~

如果你也是因为不太了解Jackson而不敢离开温室，那么看到本文就很幸运了，本系列会免费带你拥抱Jackson这个高级JSON库，功能上比Fastjson强了不止一点点。

正文

坊间在某坛里看到这样一句言论：若你还依赖于使用Fastjson，那么你大概率还只是初/中级水平。这句话必然让Fastjson的忠实用户火冒三丈，抄起家伙嘎嘎就是干。话出必然有因，那么这句话是否真的言过于词呢？接下来就絮叨絮叨

我很愿意用 存在即合理 原则来表达一个观点：Fastjson出个bug就能有这么高的关注度，不可否认这本身就是一种成功。

误区描述：“合理”请不要误读为“合乎情理”之类，而是当做“理由”来讲。“存在即合理”正确理解为：一切存在的事物都有它存在的理由

任何技术能够流行起来，well-known被我们所熟知必然有它的优势，哪怕这个过人之处 只有一个 。下面我们来看看为何Fastjson能一步步被宠爱，它的魔力到底在哪？

技术选型不应该像相亲：肯定你只需要一个理由，而否定你却能...

Fastjson到了说再见的时候了

Why Fastjson？

虽然最近Fastjson由于出现安全漏洞，社区言论一边倒。即使如此，几乎没人直接否定过Fastjson本身的优秀，特别是当你知道这个使用广泛的库几乎全部来自于一人之手时。他就是匠人温少：

值得一提的是：温少另一个开源项目Druid是国内最流行的（甚至没有之一）数据库连接池产品，广受好评

成人只看利弊，小孩才分对错。为何要使用它能流行开来，那必然是因为它优秀。它优秀品质在其官网可一览无遗：

这些“优点”用中文描述出来更加直（震）观（撼）：

1、速度快

fastjson相对其他JSON库的特点是快，从2011年fastjson发布1.1.x版本之后，其性能 从未被 其他Java实现的JSON库超越。

话外音：速度/性能这一块，Fastjson一直拿捏得死死的

Fastjson到了说再见的时候了

2、使用广泛

fastjson在阿里巴巴大规模使用，在数万台服务器上部署，fastjson在业界被广泛接受。在2012年被开源中国评选为最受欢迎的国产开源软件之一。

话外音：阿里巴巴数以万计的大规模集群实例做规模背书，说服力杠杠的

Fastjson到了说再见的时候了

3、测试完备

fastjson有非常多的testcase，在1.2.11版本中，testcase超过3321个。每次发布都会进行回归测试，保证质量稳定。

话外音：单测覆盖率高，代码健壮性有保证

Fastjson到了说再见的时候了

4、使用简单

fastjson的API十分简洁。

String text = JSON.toJSONString(obj); //序列化
VO vo = JSON.parseObject("{...}", VO.class); //反序列化

话外音：不管你是小白还是小小白，轻松上手，使用起来都无障碍

Fastjson到了说再见的时候了

5、功能完备

支持泛型，支持流处理超大文本，支持枚举，支持序列化和反序列化扩展。

话外音：我这一家就够了，你要的，这都有

Fastjson到了说再见的时候了

Why Not Fastjson？

Fastjson到了说再见的时候了文首有表态本文我是有态度和有偏向的，因此不来几点原因实则不妥。那么我就针对于官网列出的5点（见上），给出个人观点供以参考。是否言过于辞，咱们拿出另外一个JSON库做出对比，本文以Jackson为例。

版本约定

因为要做比较嘛，所以对使用的JSON库做出版本约定：

Jackson：2.10.1
- 演示代码均使用最常用的 高层API ，而非底层API。毕竟用底层API去PK Fastjson并不公平，毕竟那并不常用
Fastjson：1.2.72
- only one jar

1、速度上并没有那么的快

速度快/性能高是Fastjson 最最最最最最 大的“卖点”，可谓是 立身之本 ，从它的命名以及它的logo设计上你都能感受到这一点。

没有调研就没有发言权，本文针对于 最常用 的使用场景来一波测试对比（对比尽量公正，切勿钻牛角尖）。关于Fastjson和Jackson在性能PK这一块，网上的案例有不少，我自己也书写了多个场景的比较代码。但最终我还是决定引用Robin的结果展示给大家，我看了他的测试方案（代码）更加专业些：几种常用 JSON 库性能比较，结论如下两张图