前言

本篇文章是我这一个多月来帮助组内废弃fastjson框架的总结，咱们将大部分Java仓库从fastjson迁移至了Gson。java

这么作的主要的缘由是公司受够了fastjson频繁的安全漏洞问题，每一次出现漏洞都要推一次全公司的fastjson强制版本升级，很令公司头疼。git

文章的前半部分，我会简单分析各类json解析框架的优劣，并给出企业级项目迁移json框架的几种解决方案。github

在文章的后半部分，我会结合这一个月的经验，总结下Gson的使用问题，以及fastjson迁移到Gson踩过的深坑。web

文章目录：spring

为什么要放弃fastjson？
fastjson替代方案

三种json框架的特色
性能对比
最终选择方案

替换依赖时的注意事项

谨慎，谨慎，再谨慎
作好开发团队和测试团队的沟通
作好回归/接口测试
考虑迁移先后的性能差别

使用Gson替换fastjson

Json反序列化
范型处理
List/Map写入
驼峰与下划线转换

迁移常见问题踩坑

Date序列化方式不一样
SpringBoot异常
Swagger异常
@Mapping JsonObject做为入参异常

注意：是否使用fastjson是近年来一个争议性很大的话题，本文无心讨论框架选型的对错，只关注迁移这件事中遇到的问题进行反思和思考。你们若是有想发表的见解，能够在评论区理性讨论。json

本文阅读大概须要：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是一件复杂且痛苦的事情，其实对于其余依赖的替换，也都同样。

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

谨慎，谨慎，再谨慎

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

因此，谨慎点！

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

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

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

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

而对于测试，更要事先沟通好。通常来讲，测试不会太在乎这种对于业务没有变化的技术项目，由于既不是优化速度，也不是新功能。但其实迁移涉及到了底层，很容易就出现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\":\"小李\"}]";

// fastjson
JSONArray 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}]
// 小明
// 小李

// Gson
JsonArray 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 = "{}";

// fastjson
JSONObject jsonObjectEmpty = JSON.parseObject(jsonObjectEmptyCase);
System.out.println(jsonObjectEmpty);
System.out.println(jsonObjectEmpty.size());
// 输出：
// {}
// 0

// Gson
JsonObject jsonObjectGsonEmpty = gson.fromJson(jsonObjectEmptyCase, JsonObject.class);
System.out.println(jsonObjectGsonEmpty);
System.out.println(jsonObjectGsonEmpty.size());
// 输出：
// {}
// 0

没有异常，开心。

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

String jsonArrayEmptyCase = "[]";

// fastjson
JSONArray jsonArrayEmpty = JSON.parseArray(jsonArrayEmptyCase);
System.out.println(jsonArrayEmpty);
System.out.println(jsonArrayEmpty.size());
// 输出：
// []
// 0

// Gson
JsonArray 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("马云");

// fastjson
List<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]

// Gson
List<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("马云");

// fastjson
JSONObject jsonObject1 = new JSONObject();
jsonObject1.put("user", user);
jsonObject1.put("userList", userList);
System.out.println(jsonObject1);
// 输出：
// {"userList":[{"id":1,"userName":"马云"},null],"user":{"id":1,"userName":"马云"}}

// Gson
JsonObject 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 conversion
spring.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/

GsonSwaggerConfig.java

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

IGsonHttpMessageConverter.java

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

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

往期精彩文章：

绝了，几款主流的 JSON 库性能对比！

Java中经常使用的4个Json库，哪一个性能更牛逼？

这个 bug 让我更加理解 Spring 单例了

本文分享自微信公众号 - Java中文社群（javacn666）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。

废弃fastjson！大型项目迁移Gson保姆级实战

前言

为什么要放弃fastjson？

fastjson替代方案

三种json框架的特色

FastJson

Jackson

Gson

性能对比

最终选择方案

替换依赖注意事项

谨慎，谨慎，再谨慎

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

作好回归/接口测试

考虑迁移先后的性能差别

使用Gson替换Fastjson

Json反序列化

范型处理

List/Map写入

驼峰与下划线转换

常见问题排雷

Date序列化方式不一样

SpringBoot异常

Swagger异常

@Mapping JsonObject做为入参异常

总结

参考