欢迎光临散文网 会员登陆 & 注册

fastjson很好,但不适合我

2023-04-05 09:57 作者:刘小六六不六  | 我要投稿

记者:大爷您有什么特长呀?
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 #24524个。
解决问题的版本为: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只能放任。


fastjson很好,但不适合我的评论 (共 条)

分享到微博请遵守国家法律