大家好，又双叒叕见面了，我是天天放大家鸽子的蛮三刀。
在被大家取关之前，我立下一个“远大的理想”，一定要在这周更新文章。现在看来，flag有用了。。。
本篇文章是我这一个多月来帮助组内废弃fastjson框架的总结，我们将大部分Java仓库从fastjson迁移至了Gson。
这么做的主要的原因是公司受够了fastjson频繁的安全漏洞问题，每一次出现漏洞都要推一次全公司的fastjson强制版本升级，很令公司头疼。
文章的前半部分，我会简单分析各种json解析框架的优劣，并给出企业级项目迁移json框架的几种解决方案。
在文章的后半部分，我会结合这一个月的经验，总结下Gson的使用问题，以及fastjson迁移到Gson踩过的深坑。
文章目录：
为何要放弃fastjson？
fastjson替代方案
三种json框架的特点
性能对比
最终选择方案
替换依赖时的注意事项
谨慎，谨慎，再谨慎
做好开发团队和测试团队的沟通
做好回归/接口测试
考虑迁移前后的性能差异
使用Gson替换fastjson
Json反序列化
范型处理
List/Map写入
驼峰与下划线转换
迁移常见问题踩坑
Date序列化方式不同
SpringBoot异常
Swagger异常
@Mapping JsonObject作为入参异常
注意：是否使用fastjson是近年来一个争议性很大的话题，本文无意讨论框架选型的对错，只关注迁移这件事中遇到的问题进行反思和思考。大家如果有想发表的看法，可以在评论区 理 性 讨论。
本文阅读大概需要：5分钟
码字不易，欢迎关注我的个人公众号：后端技术漫谈
为何要放弃fastjson？究其原因，是fastjson漏洞频发，导致了公司内部需要频繁的督促各业务线升级fastjson版本，来防止安全问题。
fastjson在2020年频繁暴露安全漏洞，此漏洞可以绕过autoType开关来实现反序列化远程代码执行并获取服务器访问权限。
从2019年7月份发布的v1.2.59一直到2020年6月份发布的 v1.2.71 ，每个版本的升级中都有关于AutoType的升级，涉及13个正式版本。
fastjson中与AutoType相关的版本历史：
1.2.59发布，增强AutoType打开时的安全性 fastjson 1.2.60发布，增加了AutoType黑名单，修复拒绝服务安全问题 fastjson 1.2.61发布，增加AutoType安全黑名单 fastjson 1.2.62发布，增加AutoType黑名单、增强日期反序列化和JSONPath fastjson 1.2.66发布，Bug修复安全加固，并且做安全加固，补充了AutoType黑名单 fastjson 1.2.67发布，Bug修复安全加固，补充了AutoType黑名单 fastjson 1.2.68发布，支持GEOJSON，补充了AutoType黑名单 1.2.69发布，修复新发现高危AutoType开关绕过安全漏洞，补充了AutoType黑名单 1.2.70发布，提升兼容性，补充了AutoType黑名单 1.2.71发布，补充安全黑名单，无新增利用，预防性补充相比之下，其他的json框架，如Gson和Jackson，漏洞数量少很多，高危漏洞也比较少，这是公司想要替换框架的主要原因。
fastjson替代方案本文主要讨论Gson替换fastjson框架的实战问题，所以在这里不展开详细讨论各种json框架的优劣，只给出结论。
经过评估，主要有Jackson和Gson两种json框架放入考虑范围内，与fastjson进行对比。
三种json框架的特点 FastJson速度快
fastjson相对其他JSON库的特点是快，从2011年fastjson发布1.1.x版本之后，其性能从未被其他Java实现的JSON库超越。
使用广泛
fastjson在阿里巴巴大规模使用，在数万台服务器上部署，fastjson在业界被广泛接受。在2012年被开源中国评选为最受欢迎的国产开源软件之一。
测试完备
fastjson有非常多的testcase，在1.2.11版本中，testcase超过3321个。每次发布都会进行回归测试，保证质量稳定。
使用简单
fastjson的API十分简洁。
Jackson容易使用 - jackson API提供了一个高层次外观，以简化常用的用例。
无需创建映射 - API提供了默认的映射大部分对象序列化。
性能高 - 快速，低内存占用，适合大型对象图表或系统。
干净的JSON - jackson创建一个干净和紧凑的JSON结果，这是让人很容易阅读。
不依赖 - 库不需要任何其他的库，除了JDK。
Gson提供一种机制，使得将Java对象转换为JSON或相反如使用toString()以及构造器（工厂方法）一样简单。
允许预先存在的不可变的对象转换为JSON或与之相反。
允许自定义对象的表现形式
支持任意复杂的对象
输出轻量易读的JSON
性能对比同事撰写的性能对比源码：
https://github.com/zysrxx/json-comparison
本文不详细讨论性能的差异，毕竟这其中涉及了很多各个框架的实现思路和优化，所以只给出结论：
1.序列化单对象性能Fastjson > Jackson > Gson，其中Fastjson和Jackson性能差距很小，Gson性能较差
2.序列化大对象性能Jackson> Fastjson > Gson ，序列化大Json对象时Jackson> Gson > Fastjson，Jackson序列化大数据时性能优势明显
3.反序列化单对象性能 Fastjson > Jackson > Gson , 性能差距较小
4.反序列化大对象性能 Fastjson > Jackson > Gson , 性能差距较很小
最终选择方案Jackson适用于高性能场景，Gson适用于高安全性场景
对于新项目仓库，不再使用fastjson。对于存量系统，考虑到Json更换成本，由以下几种方案可选：
项目未使用autoType功能，建议直接切换为非fastjson，如果切换成本较大，可以考虑继续使用fastjson，关闭safemode。
业务使用了autoType功能，建议推进废弃fastjson。
替换依赖注意事项企业项目或者说大型项目的特点：
代码结构复杂，团队多人维护。
承担重要线上业务，一旦出现严重bug会导致重大事故。
如果是老项目，可能缺少文档，不能随意修改，牵一发而动全身。
项目有很多开发分支，不断在迭代上线。
所以对于大型项目，想要做到将底层的fastjson迁移到gson是一件复杂且痛苦的事情，其实对于其他依赖的替换，也都一样。
我总结了如下几个在替换项目依赖过程中要特别重视的问题。
谨慎，谨慎，再谨慎