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

前言

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

我的态度

我在 CSDN 写过好些篇对于 JSON 的文章，特地是 2020 年专门写了一个付费专栏：享学 Jackson


这个专栏“销量”在我心目中还对付，4 个月“卖出”200 份的样子（虽不值一提，但我很满足了????），小小的一个 JSON 库而已，热度可见一斑。专栏里不可避免的提到了 Jackson 和 Fastjson 的比拟，我自己始终持中立态度，次要起因有二：

1. 两者都很风行（国内 Fastjson 风行度甚至超过 Jackson），因而平时开发中我 两者都用（须要随大流嘛）
2. 国产开源软件是须要被反对的，即便当初还存在差距（联想下 最后的 国产手机和苹果手机的差距，再看看当初呢？）

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

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

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

2020-05-30 阿里云应急响应核心监测到 Fastjson 暴发新的反序列化近程代码执行破绽，黑客利用破绽，可绕过 autoType 限度，间接近程执行任意命令攻打服务器，危险极大 （话外音：此 bug 必须 Fix）。侥幸的是，官网的响应速度十分快：

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

当然，之前也有些破绽问题，但关注度不如这两次。次要是这两次工夫相近，危险级别十分高影响面很大，所以社区反馈较为强烈

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

针对此破绽，虽说咱们 Fix 起来步骤简略：降级 Fastjson 的版本，而后重启利用。看起来毫不费力，实则是个大坑。你是否曾想过这个问题：假使有上百个、几百个 Java 利用呢？且不谈你操作上的工夫和人力老本有多高，单单 治理 起来的工作量也不容小觑。所以如果你是技术 Leader，胸中的怒火开释一下是在情理之中的。

置信很少有部门 / 团队把 Spring Boot 利用做成 Jar 包拆散 的模式的吧~ 因而大概率都须要通过升版本 -> 提交代码 -> 合代码 -> 上 pre -> 上线 -> 验证等步骤，so 还是比拟麻烦的

你为何用 Fastjson？

这个问题你能够问本人，也能够问身边的共事。汇总一下就是答案，这才是来自用户最实在的声音嘛。我针对此也简略“考察”过，把我听到的理解到的汇总为如下三点：

1. API 简略（static 办法间接应用），上手快，对开发者敌对
2. 阿里巴巴出品，背靠大厂值得信赖.
3. 社区绝对沉闷，保护降级有保障

容我猜猜，这 3 个理由大概率命中了你心中所想吧????？有大厂做背书天然能给产品加分，但本身优良才是硬道理。尽管起因有三点，但我认为让很多人决定去应用它、赞它的最最最次要起因其实就一点：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 能一步步被钟爱，它的魔力到底在哪？

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

Why Fastjson？

尽管最近 Fastjson 因为呈现安全漏洞，社区舆论一边倒。即使如此，简直没人间接否定过 Fastjson 自身的优良，特地是当你晓得这个应用宽泛的库简直全副来自于一人之手时。他就是匠人温少：

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

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

这些“长处”用中文形容进去更加直（震）观（撼）：

1、速度快

fastjson 绝对其余 JSON 库的特点是快，从 2011 年 fastjson 公布 1.1.x 版本之后，其性能 从未被 其余 Java 实现的 JSON 库超过。

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

2、应用宽泛

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

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

3、测试齐备

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

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

4、应用简略

fastjson 的 API 非常简洁。

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

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

5、性能齐备

反对泛型，反对流解决超大文本，反对枚举，反对序列化和反序列化扩大。

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

Why Not 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 库性能比拟，论断如下两张图

总的论断：除了 Json-lib 是来搞笑的（它早已进行更新，切勿在生产上应用），Fastjson、Jsckson、Gson 三者不分伯仲，差异性较小。

综合各种测试 case，网上的 + 我本人写的测试用例，三者在性能方面除了 Gson 略微差点外，Jackson 和 Fastjson 在速度上可认为是差不多的（甚至 Jackson 综合性能体现更好）

既然差异性这么小，Fastjson 一味的强调它是最快的真的有意义吗？

JSON 的解析速度绝不会制约零碎的性能

比方咱们一次 REST 调用环节全流程可能 100ms；其中操作一次数据库，可能须要几十 ms；序列化反序列化一次 json 个别只须要几 ms；也就是说不同的 json 库，性能相差都在毫秒间；在一次 REST 调用全流程里，不同的 JSON 库在性能体现上影响甚微。

在古代应用程序中，即便最慢的 Gson，也是满足需要的；解析文档速度的快慢，并不能作为选型的唯一标准，可能连次要规范都算不上。对 IO 优化、网络优化、并行处理等优化措施，远比选用一个更快的库更无效。

言而总之，如果你抉择一个 JSON 库把性能当作了一个规范，就犯了方向性的谬误。

2、并没有那么的风行

应用广不宽泛、风行度有多高这玩意是绝对的。有一个最直观的数据，那就是在 Maven 中的援用量，我截图如下：



从 usages 数值上看，仿佛不在一个量级上。当然这么比拟我集体认为不算特地主观，次要起因有二：

1. 开源的技术倒退的越早，使用者越多，支流框架越反对（比方 Spring MVC 内置 Jackson 反对），就会造成汇集效应，赢者通吃
2. Fastjson 起步较晚，且次要发力于国内

不可否认 Fastjson 在国内的风行度是十分高的，甚至超过 Jackson。否则最近一次的安全漏洞也不会有那么多人吃瓜嘛，然而这种“应用宽泛”你也得辩证性的去看，毕竟在中国 Java 畛域里，阿里巴巴是相对的执牛耳者。

Fastjson 的风行，是有着外在的起因的，比方这个无奈：

3、测试真的齐备吗？

额，这个我只能说：Fastjson 本人晓得就成，并无必要当作亮点 show 进去，毕竟使用者只关怀出 bug、出破绽的频率和严重性，并不关怀工程外部是如何保障健壮性的。

在使用者眼中：不出 bug，一行单测没有都没关系。出了重大 bug，有上万个 test case 也难以让人服气。

4、API 真的简略吗？

答：真的。文上有解释，这兴许可能大略是你抉择应用 Jackson 作为 JSON 库最重要的理由。

当然，API 应用简略针对于 simple 场景，对于简单场景它也并不能简略应答。情理很简略，POP is simple,OOP is Complex。但恰好的是，在互联网利用场景中应用 JSON 库，大多属于简略场景，因而 Fastjson 把它当做一个亮点我感觉是无可非议的。

5、性能并没有那么齐备

官网强调了它是反对泛型、枚举等类型的序列化、反序列化的。然而对着 JavaBean + JSON 标准来讲，Fastjson 有不少性能缺失（没遵循标准），这是 A 哥最为忍耐不了的中央，因为它曾经不能实现我的性能了。如果你基于它做过中间件开发、框架开发或者是 DDD 驱动设计开发，置信你也深有体会：

总结

真谛是绝对的，没有相对的真谛。真谛是让人明确情理的，不是用来诡辩的，更不是用来抬扛的。

同样的，Fastjson 还是 Jackson 也就没有规范的答案，各位还是联合本人的具体情况，见仁见智。本文只是论述我的 个人观点，表白了我的应用偏向，供以你决策时参考。

如果你和我一样，也想把 Jackson 作为你的 惟一 JSON 库，那就关注我吧，接下来我会把付费专栏里的内容全副搬过去给你，收费助你平滑过渡到这个世界上最好的 JSON 库。

关注 A 哥