其出处为，juejin.cn/post/7215886869199863869。
很高兴迎接你，你会得到：专门为你定制的项目实战机会，面向Java的学习线路，一个一对一提问的渠道，用于自律学习的打卡方式，以及每月赠送书籍之举。
新项目，是仿小红书那种微服务架构的正在更新着，全栈前后端分离的博客项目 2.0 版本完成了，演示链接是这个：http://116.62.199.48/。整个过程是手把手地教，后端加上前端全栈性开发，从最开始一直到 1 讲解每个功能点发展开来的步骤，还会进行 1v1 答疑解惑，一直到项目上线。如秒杀系统，在线商城，IM即时通讯，Spring Cloud Alibaba等等，目前已经更新了261小节，累计字数达到41w+，讲解图有1806张，虽然还在持续非常努力地更新中，但后续依旧会推出更多项目，目标是把Java领域里典型的项目全部都涵盖一遍。
这样一个稍微有点呈现出马丽苏特质的标题，各位看客就暂且凑合着看一下吧。主要是心里害怕会遭到他人的批评指责。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的问题编号，关键集中在此#1868，这常常是github的问题编号。
对于开源项目而言，要是解决了 BUG，一般会将问题编号放置到注释当中去，其所具备的前提条件是注释存在必要性，借助问题编号能够看到问题的内在根源以及后续结果。
一般来讲，针对github开源项目而言，是存在issue区的，凭借这个去到编号处，直接在issue那里进行搜索，便能够搜索到。
可是呢，存在着一部分顶级的项目，举个例子来说，像spark，还有flink，它们是不存在issue区的，它们对于各类问题的发现、描述以及追踪，全都运用jira平台。
如：https://issues.apache.org/jira/browse/SPARK-38349%EF%BC%8C 在提交PR的时候标题也严格按照
jira 编号
spark 子模块(如core/sql) title
的规则来。
故而，拿着此编号前往issue区，无论是否存在issue区，均可直接于pullrequest区径直寻觅，即便PR标题内缺乏问题编号，PR描述必定也是有的，只要是具备严谨PR流程的开源项目。
所以这个问题在这里
https://github.com/alibaba/fastjson/issues/1868
相应的PR在这里
https://github.com/alibaba/fastjson/pull/2706
凭着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只能任由其存在。
图片
这个项目的荣誉感没那么强，或者说没那么吸引厉害的人，它不是apache顶级项目，像spark/flink 、 spring ，哪怕是 dubbo也是如此，很难想象这些项目会存在一个不算复杂的BUG ，且一直没解决长达3年时间。在这些顶级开源项目里，大家都竭尽全力想找出BUG并提交PR。
当然，以上只是我个人的一点猜测。
反复回顾，碰到Fastjson的状况，从起初就应当朝着github的问题板块去，它很有可能早就被之前的人遭遇过问题了。
$ref循环引用问题
public?ResultBody?test?()?{
????List?list?=?new?ArrayList<>();
????Person?obj1?=?new?Person("张三",?48);
????list.add(obj1);
????Person?obj2?=?new?Person("李四",?23);
????list.add(obj2);
????Person?obj3?=?new?Person("王麻子",?17);
????list.add(obj3);
????List?young?=?list.stream().filter(e?->?e.getAge()?<=?45).collect(Collectors.toList());
????List?children?=??list.stream().filter(e?->?e.getAge()
????HashMap?map?=?new?HashMap();
????map.put("young",?young);
????map.put("children",?children);
????return?ResultBody.success(map);
}
以上测试接口返回前端什么？
{
?"code":"200",
?"message":"成功!",
?"result":{
??"young":[
???{
????"age":23,
????"name":"李四"
???},
???{
????"age":17,
????"name":"王麻子"
???}
??],
??"children":[
???{"$ref":"$.result.young[1]"}
??]
?}
}
我现在并不知道什么循环引用检测，这时候它是我的知识盲区。
这时，我所观察到的情形是，young与children这两个list对象之中，都存在引用指向了王麻子这个对象。接着，在第2次children进行引用时，它于序列化之际直接指向了第1个young里对应的对象引用。
当遇到这个问题之时，对其进行仔细观察，经过排查将非fastjson的问题予以排除之后，这次我变得机灵了，直接去到github的issues区，去搜索$ref。
图片
的确存在不少志同道合之人，将近一百五十个问题，从时间层面予以考量还蛮新颖。我轻点了closed，既然已然关闭，那想必是已解决了吧。
我点击进入了处于closed状态的区域里的第一个问题，随后这个时候作者要求升级成为fastjson2???
图片
倘若我没有领会错，fastjson跟fastjson2并非是两个版本之间的那种区别，而是两个项目哪！听说API也存在兼容性方面的问题。就这么直接升级过去，岂是容易之事！
我觉着这同样是个能吐槽之处，Fastjson似乎并不存在一个稳稳当当进行维护的版本，碰到问题老是处于升级状态，在升级的进程当中也没把质量把控给做好，还引入了新的问题。
还是在当前项目寻求解决方法吧，哪怕升版本也好啊。
终于在另一个问题下面找到了问题所在以及解决方案。
https://github.com/alibaba/fastjson/issues/3643
现如今，我晓得这是因循环引用检测所引发的。借助于将SerializerFeature.DisableCircularReferenceDetect进行设定，能够让这个问题得以避免。
然而，实际上我的代码并非存在循环引用这一情况哟，只不过是有着两个子对象对同一个对象进行引用罢了，这究竟算作啥呀，算得上是被错误地伤害到了吗？
更重要的，一些控制权应该在使用者手里？
比如说，目前这个循环引用于序列化时会出现的问题，应当是由用户手动去进行开启，并非是默认就给用户开启的。
全局在优先级这方面，按照要求应当予以关闭，在存在一处有着循环引用情况的地方，给用户得以采取选择局部开启的方式。
此刻，我的前端未曾运用Fastjson，针对“$ref":"$.result.young"这般的文本描述，它能够进行解析吗？它是无法做到的呀。我开展了一次测试，仿佛运用fastjson同样无法将其解析还原：
图片
注释，经过提醒，此处应该采用完整报文解析，经过测试，的确是可行的。多谢提醒！
更为可怕的问题呈现出来了，恰巧在测试的这个环节当中，有两个子对象对同一个对象进行了引用，而这还被我提前给发现了。要是测试的环境不存在这样的状况，然而在生产的环境当中却恰好碰到了呢？那可就会演变成生产事故了呀。
原本是个挺不错的设计要点，能够发挥出增添光彩的功效，然而它却极有可能出现问题，这属于怀着好意却办了糟糕的事。
相仿的是，存在所谓的，名为SerializerFeature.WriteMapNullValue的事物。
倘若是有着一个字段值为null这种情况，fastjson按默认的话就不会对该字段进行返回了。原本在前后端之间是已经约定好了的那般，要是为null就要怎样去处理的相关逻辑，然而在生产环境里却有可能就这样突然出现问题了啊。
就如同WriteNullListAsEmpty这般挺好，是不错的一个设计关键点，假定返回出来的list显现为null之际，用户能够拥有选择使其序列化为的权利之举，但是它并非是默认处于开启状态哒，给予了用户额外的可供选择权力没错吧，对不。
总结
写至此处之际，我实实在在地觉着fastjson较之于竞品存在着某些具特色之处，这绝非是为了那所谓客观公正，非得更多地书写负面内容，而后再添加上些许正面的。
撰写文章时，必然要进行试验，需将竞品取出予以测试 ，测试后发觉并非fastjson独自具备的 ，尴尬呀！
可是我依旧要讲那句话，不论你相不相信，就开源项目而言，尤其是像这样一个被广泛运用的开源项目，必定存在极为值得去学习的地方。一个开源项目啊，要是成天拿着显微镜去进行观察，那么肯定能够找出不少的毛病来。
这儿略微整理一下此篇文章之中的那些信息要点了。可不必然是某特定的一个BUG哟，而是凭借这个BUG哩，去处理这项这个BUG背后所透显呈现而闪现出来来的fastjson的那些信息或是些往前往后的趋势呢。
review、testcase覆盖不是很到位
供稿者看上去数目不少，然而却严重依靠主要人员，而主要人员精力存在限度，某些优先等级并非那么高的漏洞只好听之任之。
这个项目的荣誉感并没有那么高，或者叫并没有那么吸引高手）。
存在一些功能点，其控制主动权应当交付给用户，像DisableCircularReferenceDetect、WriteMapNullValue这类，仅仅默认开启便极易致使线上出现问题。
就作者而言，已然是全面地转向了fastjosn2，并且，哪怕是在这之前，针对于fastjson，并不存在一个能够稳定维护的版本，处于持续不断地升级状态，还持续不停地引入新的问题。
期盼fastjson2能够渐入佳境，持续向好发展，切不可重蹈struts2的覆辙，步入类似的不良境地。
欢迎?，你将获得:?专属的项目实战 / Java 学习路线 /?一对一提问 / 学习打卡 /? 每月赠书
新项目:仿小红书(微服务架构)正在更新中... , 全栈前后端分离博客项目 2.0 版本完结啦，?演示链接：http://116.62.199.48/?。全程手摸手，后端 + 前端全栈开发，从 0 到 1 讲解每个功能点开发步骤，1v1 答疑，直到项目上线。目前已更新了261小节，累计41w+字，讲解图：1806张，还在持续爆肝中..?后续还会上新更多项目，目标是将Java领域典型的项目都整一波，如秒杀系统, 在线商城, IM即时通讯，Spring Cloud Alibaba 等等，
1.?我的私密学习小圈子~
最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式：点“在看”，关注公众号并回复?Java?领取，更多内容陆续奉上。
PS：因公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。
点“在看”支持小哈呀，谢谢啦
