记一次细思极恐的FastJson差点引发的大面积故障

主要观点总结

作者记录了一次FastJson可能引发的大面积故障排查过程和解决方案。文章主要描述了问题现象、排查过程、问题定位以及总结反思。

关键观点总结

关键观点1: 问题现象

突然有一天组里同学告诉作者预发有大量报错，涉及FastJson反序列化的问题，影响面广泛。

关键观点2: 排查过程

作者首先怀疑FastJson版本问题，查看了pom文件改动情况，并检查了FastJson相关类的加载情况。接着排查了Kotlin相关依赖，并确认了JDK近期没有变动。最后通过网上查阅资料，找到了类似问题的解决方案和关键点。

关键观点3: 问题定位

问题定位到了一个具体的代码段，其中对resumeBody字段的赋值有误，使用了{}而非预期的空对象或函数。这个错误导致了FastJson无法正确解析该字段，进而引发全局异常。

关键观点4: 总结反思

作者总结了问题的原因和解决方案，并反思了多语言混编的注意事项、灰度发布的重要性、框架的安全性和Bug经验的价值。

文章预览

阿里妹导读 作者记录了一次FastJson差点引发的大面积故障的排查过程和解决方案。 在短短不到两年的开发生涯里，加上这次，印象中已经碰到过至少3次FastJson的问题了。而且FastJson不同版本之间的差异很大，各位同学在使用时一定注意不要踩坑。  下面讲一下我碰到的这个细思极恐的问题。 一、首先讲讲工程背景 我们的工程是Kotlin与Java混编的，再附加偶尔写写Groovy，在团队中不断熟悉后发现各语言在编程中各有利弊。 Java就不说了，阿里在国内Java应用上堪称鼻祖，集团各种工具对Java的支持都比较完备； Kotlin有很多语法上的优势，同样的代码Java 10行，Kotlin可能只需要5行，此外支持协程（coroutines），编写非阻塞异步代码看起来像是同步的，能很好地处理IO密集型任务。但是Kotlin毕竟非正统，集团很多工具对Kotlin的支持性比较一般； groovy的语法规 ………………………………