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
性能对比
本文不详细讨论性能的差异,毕竟这其中涉及了很多各个框架的实现思路和优化,所以只给出结论:
-
序列化单对象性能Fastjson > Jackson > Gson,其中Fastjson和Jackson性能差距很小,Gson性能较差
-
序列化大对象性能Jackson> Fastjson > Gson ,序列化大Json对象时Jackson> Gson > Fastjson,Jackson序列化大数据时性能优势明显
-
反序列化单对象性能 Fastjson > Jackson > Gson , 性能差距较小
-
反序列化大对象性能 Fastjson > Jackson > Gson , 性能差距较很小
最终选择方案
Jackson适用于高性能场景,Gson适用于高安全性场景
对于新项目仓库,不再使用fastjson。对于存量系统,考虑到Json更换成本,由以下几种方案可选: 项目未使用autoType功能,建议直接切换为非fastjson,如果切换成本较大,可以考虑继续使用fastjson,关闭safemode。业务使用了autoType功能,建议推进废弃fastjson。
替换依赖注意事项
企业项目或者说大型项目的特点:
-
代码结构复杂,团队多人维护。
-
承担重要线上业务,一旦出现严重bug会导致重大事故。
-
如果是老项目,可能缺少文档,不能随意修改,牵一发而动全身。
-
项目有很多开发分支,不断在迭代上线。
所以对于大型项目,想要做到将底层的fastjson迁移到gson是一件复杂且痛苦的事情,其实对于其他依赖的替换,也都一样。
我总结了如下几个在替换项目依赖过程中要特别重视的问题。
谨慎,谨慎,再谨慎
再怎么谨慎都不为过,如果你要更改的项目是非常重要的业务,那么一旦犯下错误,代价是非常大的。并且,对于业务方和产品团队来说,没有新的功能上线,但是系统却炸了,是一件“无法忍受”的事情。尽管你可能觉得很委屈,因为只有你或者你的团队知道,虽然业务看上去没变化,但是代码底层已经发生了翻天覆地的变化。
所以,谨慎点!

(编辑:长春站长网)
【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!
|