生命太短暂，不要去做一些基本没有人想要的货色。本文已被 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哥