作者:贺子江
- 背景介绍
本篇文章是在项目迭代的过程中,发现了的一个有趣的bug所引发出来的源码分析,在这里以点破面,研究一下fastjson的源码 - 案例分析
2.1 发现问题的过程
在项目使用中,发现对于Timestamp的类型进行toJSONString()方法调用的时候,输出结构并没有按照预想的接果进行展示,后续单独拆出demo来进行研究
Timestamp timestamp = new Timestamp(System.currentTimeMillis());
JSONObject jsonObject = new JSONObject();
jsonObject.put("timestamp",timestamp);
System.out.println(jsonObject.toJSONString());
}
预期:输出Timestamp类的tostring信息
实际:输出的是Timestamp的时间戳long值
2.2 debug过程和代码分析
当我们遇到和我们想法不一样的时候,就要去看源码到底是怎么实现的。在这里我的第一反应是fastjson的bug,然后我们要去验证这是fastjson的bug还是说这是它自己的策略
调用栈追踪
public String toJSONString() {
SerializeWriter out = new SerializeWriter();
String var2;
try {
(new JSONSerializer(out)).write(this);
var2 = out.toString();
} finally {
out.close();
}return var2;
}
这里直接new啦一个序列化writer对象来进行write操作,点进去继续看
public final void write(Object object) {
if (object == null) {
this.out.writeNull();
} else {
Class> clazz = object.getClass();
ObjectSerializer writer = this.getObjectWriter(clazz);
try {
writer.write(this, object, (Object)null, (Type)null, 0);
} catch (IOException var5) {
throw new JSONException(var5.getMessage(), var5);
}
}
}
【fastjson的toJSONString()对于时间类的特殊处理源码分析——《DEEPNOVA开发者社区》】这里有一个ObjectSerializer对象是比较重要的,这里也是开始进入到了核心方法
文章图片
这里可以发现ObjectSerializer接口有很多的实现类,经过debug发现我们Timestamp对应的是序列化类是DateCodec
文章图片
点击去继续看,发现真正的实现逻辑一些很明显啦
文章图片
这里有几个if else的判断来实现一些继承了Date类的一些类的序列化的操作,其中WriteDateUseDateFormat WriteClassName UseISO8601DateFormat 这些SerializerFeature枚举类占据了很重要的角色,此时我们终于发现原来fastjson对于date的实现类有特殊的序列化操作,这里需要我们进行一些特殊配置来完成toJSONString的实现。
2.3 解决方案研究
1.遇到date的实现类,自己业务使用相关的tostring方法,不要使用原生类型,使用string替代
2.配置相关的SerializerFeature使用fastjson的类进行处理
- 两种方案的对比
3.1 遇到date的实现类,自己业务使用相关的tostring方法,不要使用原生类型,使用string替代
文章图片
文章图片
运行时间: 98ms
3.2 配置相关的SerializerFeature使用fastjson的类进行处理
文章图片
执行结果:
文章图片
运行时间:113ms
- 结论
fastjson在处理时间类型的时候其实并没有什么优势,我们在使用fastjson进行打印时间类型的时候要注意,在业务过程中,如果对时间类型有要求最好自己进行时间类型的转换,这样输出既直观又易于控制,时区的处理也更加灵活,门槛还低。当然这也只是我的个人意见,有不同的意见可以交流意见。