前言

大家好，又双叒叕见面了，我是天天放大家鸽子的蛮三刀。

在被大家取关之前，我立下一个“远大的理想”，一定要在这周更新文章。现在看来，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打开时的安全性 fastjson1.2.60发布，增加了AutoType黑名单，修复拒绝服务安全问题 fastjson1.2.61发布，增加AutoType安全黑名单 fastjson1.2.62发布，增加AutoType黑名单、增强日期反序列化和JSONPath fastjson1.2.66发布，Bug修复安全加固，并且做安全加固，补充了AutoType黑名单 fastjson1.2.67发布，Bug修复安全加固，补充了AutoType黑名单 fastjson1.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 是一件复杂且痛苦的事情，其实对于其他依赖的替换，也都一样。

我总结了如下几个在替换项目依赖过程中要特别重视的问题。

谨慎，谨慎，再谨慎

再怎么谨慎都不为过，如果你要更改的项目是非常重要的业务，那么一旦犯下错误，代价是非常大的。并且，对于业务方和产品团队来说，没有新的功能上线，但是系统却炸了，是一件“无法忍受”的事情。尽管你可能觉得很委屈，因为只有你或者你的团队知道，虽然业务看上去没变化，但是代码底层已经发生了翻天覆地的变化。

所以，谨慎点！

做好开发团队和测试团队的沟通

在依赖替换的过程中，需要做好项目的规划，比如分模块替换，严格细分排期。

把前期规划做好，开发和测试才能有条不紊的进行工作。

开发之间，需要提前沟通好开发注意事项，比如依赖版本问题，防止由多个开发同时修改代码，最后发现使用的版本不同，接口用法都不同这种很尴尬，并且要花额外时间处理的事情。

而对于测试，更要事先沟通好。一般来说，测试不会太在意这种对于业务没有变化的技术项目，因为既不是优化速度，也不是新功能。但其实迁移涉及到了底层，很容易就出现 BUG。要让测试团队了解更换项目依赖，是需要大量的测试时间投入的，成本不亚于新功能，让他们尽量重视起来。

做好回归/接口测试

上面说到测试团队需要投入大量工时，这些工时主要都用在项目功能的整体回归上，也就是回归测试。

当然，不只是业务回归测试，如果有条件的话，要做接口回归测试。

如果公司有接口管理平台，那么可以极大提高这种项目测试的效率。

打个比方，在一个模块修改完成后，在测试环境（或者沙箱环境），部署一个线上版本，部署一个修改后的版本，直接将接口返回数据进行对比。一般来说是 Json 对比，网上也有很多的 Json 对比工具：

https://www.sojson.com/

考虑迁移前后的性能差异

正如上面描述的 Gson 和 Fastjson 性能对比，替换框架需要注意框架之间的性能差异，尤其是对于流量业务，也就是高并发项目，响应时间如果发生很大的变化会引起上下游的注意，导致一些额外的后果。

使用 Gson 替换 Fastjson

这里总结了两种 json 框架常用的方法，贴出详细的代码示例，帮助大家快速的上手 Gson，无缝切换！

Json 反序列化

String jsonCase = "[{\"id\":10001,\"date\":1609316794600,\"name\":\"小明\"},{\"id\":10002,\"date\":1609316794600,\"name\":\"小李\"}]";
// fastjsonJSONArray jsonArray = JSON.parseArray(jsonCase);System.out.println(jsonArray);System.out.println(jsonArray.getJSONObject(0).getString("name"));System.out.println(jsonArray.getJSONObject(1).getString("name"));// 输出：// [{"date":1609316794600,"name":"小明","id":10001},{"date":1609316794600,"name":"小李","id":10002}]// 小明// 小李
// GsonJsonArray jsonArrayGson = gson.fromJson(jsonCase, JsonArray.class);System.out.println(jsonArrayGson);System.out.println(jsonArrayGson.get(0).getAsJsonObject().get("name").getAsString());System.out.println(jsonArrayGson.get(1).getAsJsonObject().get("name").getAsString());// 输出：// [{"id":10001,"date":1609316794600,"name":"小明"},{"id":10002,"date":1609316794600,"name":"小李"}]// 小明// 小李

看得出，两者区别主要在 get 各种类型上，Gson 调用方法有所改变，但是变化不大。

那么，来看下空对象反序列化会不会出现异常：

String jsonObjectEmptyCase = "{}";
// fastjsonJSONObject jsonObjectEmpty = JSON.parseObject(jsonObjectEmptyCase);System.out.println(jsonObjectEmpty);System.out.println(jsonObjectEmpty.size());// 输出：// {}// 0
// GsonJsonObject jsonObjectGsonEmpty = gson.fromJson(jsonObjectEmptyCase, JsonObject.class);System.out.println(jsonObjectGsonEmpty);System.out.println(jsonObjectGsonEmpty.size());// 输出：// {}// 0

没有异常，开心。

看看空数组呢，毕竟[]感觉比{}更加容易出错。

String jsonArrayEmptyCase = "[]";
// fastjsonJSONArray jsonArrayEmpty = JSON.parseArray(jsonArrayEmptyCase);System.out.println(jsonArrayEmpty);System.out.println(jsonArrayEmpty.size());// 输出：// []// 0
// GsonJsonArray jsonArrayGsonEmpty = gson.fromJson(jsonArrayEmptyCase, JsonArray.class);System.out.println(jsonArrayGsonEmpty);System.out.println(jsonArrayGsonEmpty.size());// 输出：// []// 0

两个框架也都没有问题，完美解析。

范型处理

解析泛型是一个非常常用的功能，我们项目中大部分 fastjson 代码就是在解析 json 和 Java Bean。

// 实体类User user = new User();user.setId(1L);user.setUserName("马云");
// fastjsonList<User> userListResultFastjson = JSONArray.parseArray(JSON.toJSONString(userList), User.class);List<User> userListResultFastjson2 = JSON.parseObject(JSON.toJSONString(userList), new TypeReference<List<User>>(){});System.out.println(userListResultFastjson);System.out.println("userListResultFastjson2" + userListResultFastjson2);// 输出：// userListResultFastjson[User [Hash = 483422889, id=1, userName=马云], null]// userListResultFastjson2[User [Hash = 488970385, id=1, userName=马云], null]
// GsonList<User> userListResultTrue = gson.fromJson(gson.toJson(userList), new TypeToken<List<User>>(){}.getType());System.out.println("userListResultGson" + userListResultGson);// 输出：// userListResultGson[User [Hash = 1435804085, id=1, userName=马云], null]

可以看出，Gson 也能支持泛型。

List/Map 写入

这一点 fastjson 和 Gson 有区别，Gson 不支持直接将 List 写入 value，而 fastjson 支持。

所以 Gson 只能将 List 解析后，写入 value 中，详见如下代码：

// 实体类User user = new User();user.setId(1L);user.setUserName("马云");
// fastjsonJSONObject jsonObject1 = new JSONObject();jsonObject1.put("user", user);jsonObject1.put("userList", userList);System.out.println(jsonObject1);// 输出：// {"userList":[{"id":1,"userName":"马云"},null],"user":{"id":1,"userName":"马云"}}
// GsonJsonObject jsonObject = new JsonObject();jsonObject.add("user", gson.toJsonTree(user));System.out.println(jsonObject);// 输出：// {"user":{"id":1,"userName":"马云"},"userList":[{"id":1,"userName":"马云"},null]}

如此一来，Gson 看起来就没有 fastjson 方便，因为放入 List 是以gson.toJsonTree(user)的形式放入的。这样就不能先入对象，在后面修改该对象了。（有些同学比较习惯先放入对象，再修改对象，这样的代码就得改动）

驼峰与下划线转换

驼峰转换下划线依靠的是修改 Gson 的序列化模式，修改为LOWER_CASE_WITH_UNDERSCORES

GsonBuilder gsonBuilder = new GsonBuilder();gsonBuilder.setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES);Gson gsonUnderScore = gsonBuilder.create();System.out.println(gsonUnderScore.toJson(user));// 输出：// {"id":1,"user_name":"马云"}

常见问题排雷

下面整理了我们在公司项目迁移 Gson 过程中，踩过的坑，这些坑现在写起来感觉没什么技术含量。但是这才是我写这篇文章的初衷，帮助大家把这些很难发现的坑避开。

这些问题有的是在测试进行回归测试的时候发现的，有的是在自测的时候发现的，有的是在上线后发现的，比如 Swagger 挂了这种不会去测到的问题。

Date 序列化方式不同

不知道大家想过一个问题没有，如果你的项目里有缓存系统，使用 fastjson 写入的缓存，在你切换 Gson 后，需要用 Gson 解析出来。所以就一定要保证两个框架解析逻辑是相同的，但是，显然这个愿望是美好的。

在测试过程中，发现了 Date 类型，在两个框架里解析是不同的方式。

• fastjson：Date 直接解析为 Unix

• Gson：直接序列化为标准格式 Date

导致了 Gson 在反序列化这个 json 的时候，直接报错，无法转换为 Date。

解决方案：

新建一个专门用于解析 Date 类型的类：

import com.google.gson.TypeAdapter;import com.google.gson.stream.JsonReader;import com.google.gson.stream.JsonWriter;
import java.io.IOException;import java.util.Date;
public class MyDateTypeAdapter extends TypeAdapter<Date> {    @Override    public void write(JsonWriter out, Date value) throws IOException {        if (value == null) {            out.nullValue();        } else {            out.value(value.getTime());        }    }
    @Override    public Date read(JsonReader in) throws IOException {        if (in != null) {            return new Date(in.nextLong());        } else {            return null;        }    }}

接着，在创建 Gson 时，把他放入作为 Date 的专用处理类：

Gson gson = new GsonBuilder().registerTypeAdapter(Date.class,new MyDateTypeAdapter()).create();

这样就可以让 Gson 将 Date 处理为 Unix。

当然，这只是为了兼容老的缓存，如果你觉得你的仓库没有这方面的顾虑，可以忽略这个问题。

SpringBoot 异常

切换到 Gson 后，使用 SpringBoot 搭建的 Web 项目的接口直接请求不了了。报错类似：

org.springframework.http.converter.HttpMessageNotWritableException

因为 SpringBoot 默认的 Mapper 是 Jackson 解析，我们切换为了 Gson 作为返回对象后，Jackson 解析不了了。

解决方案：

application.properties 里面添加：

#Preferred JSON mapper to use for HTTP message conversionspring.mvc.converters.preferred-json-mapper=gson

Swagger 异常

这个问题和上面的 SpringBoot 异常类似，是因为在 SpringBoot 中引入了 Gson，导致 swagger 无法解析 json。

采用类似下文的解决方案（添加 Gson 适配器）：

http://yuyublog.top/2018/09/03/springboot%E5%BC%95%E5%85%A5swagger/

1. GsonSwaggerConfig.java

@Configurationpublic class GsonSwaggerConfig {    //设置swagger支持gson    @Bean    public IGsonHttpMessageConverter IGsonHttpMessageConverter() {        return new IGsonHttpMessageConverter();    }}

1. IGsonHttpMessageConverter.java

public class IGsonHttpMessageConverter extends GsonHttpMessageConverter {    public IGsonHttpMessageConverter() {        //自定义Gson适配器        super.setGson(new GsonBuilder()                .registerTypeAdapter(Json.class, new SpringfoxJsonToGsonAdapter())                .serializeNulls()//空值也参与序列化                .create());    }}

1. SpringfoxJsonToGsonAdapter.java

public class SpringfoxJsonToGsonAdapter implements JsonSerializer<Json> {    @Override    public JsonElement serialize(Json json, Type type, JsonSerializationContext jsonSerializationContext) {        return new JsonParser().parse(json.value());    }}

@Mapping JsonObject 作为入参异常

有时候，我们会在入参使用类似：

public ResponseResult<String> submitAudit(@RequestBody JsonObject jsonObject) {}

如果使用这种代码，其实就是使用 Gson 来解析 json 字符串。但是这种写法的风险是很高的，平常请大家尽量避免使用 JsonObject 直接接受参数。

在 Gson 中，JsonObject 若是有数字字段，会统一序列化为 double，也就是会把count = 0这种序列化成count = 0.0。

为何会有这种情况？简单的来说就是 Gson 在将 json 解析为 Object 类型时，会默认将数字类型使用 double 转换。

如果 Json 对应的是 Object 类型，最终会解析为 Map<String, Object>类型；其中 Object 类型跟 Json 中具体的值有关，比如双引号的""值翻译为 STRING。我们可以看下数值类型（NUMBER）全部转换为了 Double 类型，所以就有了我们之前的问题，整型数据被翻译为了 Double 类型，比如 30 变为了 30.0。

可以看下 Gson 的 ObjectTypeAdaptor 类，它继承了 Gson 的 TypeAdaptor 抽象类：

具体的源码分析和原理阐述，大家可以看这篇拓展阅读：

https://www.jianshu.com/p/eafce9689e7d

解决方案：

第一个方案：把入参用实体类接收，不要使用 JsonObject

第二个方案：与上面的解决 Date 类型问题类似，自己定义一个 Adaptor，来接受数字，并且处理。这种想法我觉得可行但是难度较大，可能会影响到别的类型的解析，需要在设计适配器的时候格外注意。

总结

这篇文章主要是为了那些需要将项目迁移到 Gson 框架的同学们准备的。

一般来说，个人小项目，是不需要费这么大精力去做迁移，所以这篇文章可能目标人群比较狭窄。

但文章中也提到了不少通用问题的解决思路，比如怎么评估迁移框架的必要性。其中需要考虑到框架兼容性，两者性能差异，迁移耗费的工时等很多问题。

希望文章对你有所帮助。

参考

《如何从 Fastjson 迁移到 Gson》

https://juejin.im/post/6844904089281626120

《FastJson 迁移至 Jackson》此文作者自己封装了工具类来完成迁移

https://mxcall.github.io/posts/%E5%B7%A5%E4%BD%9C/%E7%A8%8B%E5%BA%8F%E5%91%98/javaSE/FastJson%E8%BF%81%E7%A7%BB%E8%87%B3Jackson/

《你真的会用 Gson 吗?Gson 使用指南》

https://www.jianshu.com/p/e740196225a4

json 性能对比

https://github.com/zysrxx/json-comparison/tree/master/src/main/java/json/comparison

fastjson 官方文档

https://github.com/alibaba/fastjson/wiki

易百教程

https://www.yiibai.com/jackson

关注我

我是一名奋斗在一线的互联网后端开发工程师。

主要关注后端开发，数据安全，边缘计算等方向，欢迎交流。

各大平台都能找到我

• 微信公众号：后端技术漫谈

• **Github：@qqxx6661**

• CSDN：@蛮三刀把刀
  

• 知乎：@后端技术漫谈
  

• 掘金：@蛮三刀把刀
  

• 腾讯云+社区：@后端技术漫谈
  

• 博客园：@后端技术漫谈
  

• BiliBili：@蛮三刀把刀
  

原创文章主要内容

• 后端开发实战（Java 为主）

• 技术面试

• 算法题解/数据结构/设计模式

• 我的生活趣事

个人公众号：后端技术漫谈

如果文章对你有帮助，不妨点赞，收藏起来~