fastjson很好,但不适合我
记者:大爷您有什么特长呀?
fastjson:我很快。
记者:23423乘以4534等于多少?
fastjson:等于2343.
记者:??
fastjson:你就说快不快吧!
这个略显马丽苏的标题,各位看官将就着看吧。主要是怕被喷。fastjson真的很好,我用不用我喜不喜欢的,太不重要了,我只是觉得不适合我而已。
话说以前GSON用得好好的,同事极力推荐我使用Fastjson,说很快云云。尽管我们的系统根本感知不出来这点速度差异。
之前也听说Fastjson爆出来什么重大漏洞,但对我们基本没什么影响,所以这一点倒是没什么偏见。
然后在一个新项目上,脑抽抽,把gson换成了fastjson,还把spring boot默认支持的jackson换成了fastjson。
然后就开始遇到了一些问题。先声明,这真不是尬黑,为了文章效果,故意网上扒些黑料拼凑起来,本文所提到的问题,都来源于本人最近项目的真实经历。
dateformat优先级
本来是一个风和日丽的下午,一个非常简单的改动需求。接口返回的时间只需要年月日日期类型不需要时分秒。
因为我配置全局时间格式化为yyyy-MM-dd HH:mmss
,于是我愉快的在javabean的属性上加了个注解。
@JSONField(format="yyyy-MM-dd") 复制代码
本地测试一下,没问题,提交到测试环境,搞定,完美。
然后就接到产品的疑问,改动呢?
我登上去看了一下,唉,没改到啊,日期还是带了时分秒。
我大意了啊,这么小的改动,又是在测试环境,就没加验证。
那么现在的直接问题是:fastjson关于时间配置在局部的配置没有生效,使用的还是全局配置。
现象是,开发环境windows上没有问题,测试环境linux上出现了问题。两者有什么区别呢?系统问题?
既然怀疑是两个系统导致的问题,那么就在idea里模拟一下linux系统。在 VM options 添加 -Dos.name=linux
这不能完全模拟linux系统,只针对通过
System.getproperty("os.name")
来判断当前系统做某些操作的时候有用。
通过这种方式没复现。
我又想到了远程调试。
一阵操作猛如虎,远程调试倒是能进断点,只是断点进不了第三方jar包的源码。等于白搞。
得,还是回到源码吧。拉下源码,断点,观察JSONSerializer类,主要是writeWithFormat
方法。没有发现问题。
因为怀疑是系统导致的,在源码中搜索'linux''unix'关键字,没有发现。断点整个流程重点观察了一下这部份也没有发现问题。
突然在 JSONSerializer.dateFormatPattern上发现了这段注释。
这部份涉及到了调整dateformat的问题,重点在这个#1868
,这通常是github的问题编号。
1.对于开源项目来说,解决了BUG,通常会把问题编号放到注释里面去。前提是注释有必要。通过问题编号可以看到问题的前因后果。
2.通常来说,对于github开源项目都有issue区,拿着这个到编号直接到issue一搜就能搜到。
3.但也有一些项级项目,如spark,flink是没有issue区的,它们的类型问题发现描述追踪都使用jira平台。
如:issues.apache.org/jira/browse… 在提交PR的时候标题也严格按照[jira 编号][spark 子模块(如core/sql) title]的规则来。
所以拿着这个编号到issue
区,不管有没有issue
区,也都可以直接到pullrequest
区直接搜索,就算PR标题里没有问题编号,PR描述肯定也是有的,只要是有严格PR流程的开源项目。
所以这个问题在这里
github.com/alibaba/fas…
相应的PR在这里
github.com/alibaba/fas…
通过ISSUES描述的已知信息,可以看出他遇到的问题跟我是一样的,而这个问题早在2018年就提出了。但问题描述不太专业,没有涉及到环境以及最重要的fastjson的版本问题。
而通过PR可知,这个问题最终在2020才解决,期间仅在ISSUES区提出的相同问题就有 #1868 #1968 #2029 #2452
4个。
解决问题的版本为:1.2.72.
这个信息很关键。我对照了我开发环境的版本,是高于1.2.72的,所以没有出现测试环境的问题。
所以,柯南告诉我们,排除了所有可能性,剩下的哪怕再可笑,也是最终问题所在。
那就是,测试环境所用的fastjson版本是低于1.2.72的。
这种可能性是存在的,因为我们用的是maven打代码包,依赖包单独存在。
我最终在测试环境的依赖包目录下发现了两个Fastjson包,果然不出所料,有一个1.2.53的低版本,它就是罪魁祸首。
所以,最终这个问题有相当大的程度是由于我们团队自身问题引发的。但通过解决这个问题的过程也发现了一些有意思的情况。
首先,Fastjson在某一个版本为什么会引发这个问题。它肯定是某个PR改出问题的,rv,testcase覆盖没有到位。
其次,从试图解决这个问题的3个PR的时间线,分别在2018年,2019年,2020年。说明,fastjson这个项目的contributor看起来有百来人,但其中过于依赖其中某1个或者某些主力人员。精力有限,某些优先级不那么高的BUG只能放任。