话说在前面,本篇并不会去比较fastjson与Jackson在正常业务场景下的json解析性能,侧重点是比较两者在解析大json字符串上的性能。可以给出的结论是,jackson在解析大json场景下性能是秒杀fastjson的,不急,我们有图有真相。

我对大Json的定义是,超过1m大小的json字符串可以算是大json了。可能大家平时都没有遇到超过1m大小的json字符串,最多也就几百kb级别的,而这个级别json,fastjson与jackson解析性能比较可以参考网上的一些分析文章。

我遇到的大Json解析场景,来自第三方接口的调用。最大的有64m的json字符串,这是输出到文本文件后以文件的大小计算的。有些第三方接口没有分页的功能,我遇到一次一个接口调用返回几百万条数据的,也是从那次开始,发现fastjson的弊端。

之前测试过一次,64m的json用fastjson解析花了一个多小时,,这种场景下,fastjson不再fast。而今天我再测试一次一个只有2000条记录的json字符串解析,分别用fastjson与jackson解析,比较两者的性能。

Fastjson与Jackson性能问题_java

从测试代码中可以看出,这是一个调用第三方接口,拿到响应body之后,再分别使用fastjson与jackson测试解析耗时的例子。


方法输出:

Fastjson与Jackson性能问题_java_02

可以看到,jackson解析耗时只需要318毫秒,而fastjson却要641459毫秒,这差的不是一星半点,整整2017倍。而且json字符串越长,性能差异越大,大家可以亲自去测试一下,模拟一个超过1m大小的字符串,分别使用fastjson与jackson测试。

Fastjson其实也给出了针对这种大json解析场景的解决方案,stream api,但并不能解决大部分的业务场景。感兴趣可以去研究下。

你可能想通过缩短Json字符串解决这个问题,确实也是,谁会这么无聊,设置响应如此大数据量的接口,简直就是数据库拷贝。这确实可以通过接口支持分页解决,但你没办法让别人去改变这种设计,接口是别人家的,人家改不改是别人家的事情,我们能做的只有自己去优化。

https://mp.weixin.qq.com/s/jpW812KMyPGylQM9eXv0Ow