专栏名称: 阿里开发者

阿里巴巴官方技术号，关于阿里的技术创新均将呈现于此

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

阿里开发者 · 公众号 · 科技公司 · 2025-01-21 08:30

主要观点总结

作者记录了一次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的语法规则更加特殊，工程里用的不是特别多，所以基本都是需要开发时用大模型去解决，没有特意去研究；

二、问题现象

突然有一天组里同学告诉我预发有大量报错，是不是我改了架构层面的代码引起的。我心想肯定不是啊，我这是增量编程，并没有改动太多原来的代码。

但是处于谨慎起见，还是把分支踢掉吧，重新部署了一下，发现同样的问题在工程重启一小段时间后又发生了。

下面是问题报错，这会导致工程运行时大部分涉及反序列化的链路中断，而工程到处用了FastJson，影响面可想而知。

三、排查过程

1. 怀疑FastJson版本

既然是FastJson的抛错，那是不是有人改动了工程依赖，于是开始查pom文件的改动，一时也想不到别的原因可能导致该报错。

查了一圈并没有发现可疑的地方，于是 上AppInsights中看了一下FastJson相关类的加载情况 ，发现这里有个 1.2.68_noneautotype版本的包，而工程其实统一用的是1.2.83_noneautotype ，会不会是这里引起的呢？

后来登到线上机器对比了一下发现没有这个版本，那有可能就是别的包引入的，于是看了一下出问题module的pom文件，发现果然有这个版本的FastJson，再定位了下发现是 rass-sdk-core引入了这个包，scope为compile，打包时会将这个包编译进工程中。

很果断的将该包中的FastJson排掉，那问题铁定解决了， 观察了日志发现没有再抛错，我就没再管。到了下午同学又来反馈有问题 ，我一看还真是，难道是搞错了。

再次对比了一下预发和线上，发现还真是我搞错了，线上也有1.2.68_noneautotype。

我有点郁闷，为了定位这个bug， 翻遍了预发每个人的分支，为了排包前后部署过很多次。 此时这个问题已经困扰了我1天多了，想撂挑子放弃，到时候谁发线上时注意下好了。

但又一想这是我们辛苦维护的庞大工程，不能因为这种莫名其妙的问题引发大面积故障，到时候辛苦半年多白干（上价值，给自己增加点动力）。 理智告诉我哪怕手头的需求先放一放，还得继续查，虽然只是预发。

2. 怀疑kotlin相关依赖

跟同学确认了JDK近期也没有变动后，接下来开始到处翻资料。

大概能确认是反序列化Kotlin的data class实体时出现的问题。 类似下面这种结构

GitHub上关于该问题的讨论也比较多，总结一下解法有：

1. FastJson和kotlin版本不兼容

2. 工程中需要引入kotlin-reflect

3. 需要对data class的非空字段默认初始化

4. ……

第三个字段初始化问题不太可能，因为受影响的class从来没改动过，不可能好端端出问题。估计问题应该还是出在工程环境上。

于是去工程里看了一下 kotlin-reflect依赖，仍然是正常引入 的。

又去看了几遍近期所有分支的所有改动，也没有任何相关变动，慢慢地开始头麻，环境问题一向是最难查的。。。。

3. 翻阅到相似的例子

接下来就还是一直在网上翻阅其他资料，后来在掘金找到一篇：

https://juejin.cn/post/6929740384734019597

文章提到的问题现象跟我们的还挺像的，都是一开始正常，过了一会儿就又出现问题。

文章对FastJson剖析挺深，感觉我们的工程不至于这么奇葩吧。还提到了什么getKoltinConstructorParameters、Unit变量、kotlin_error标记位问题。 核心原因是有个静态标记位被置为异常状态。

虽然抽象，但死马当活马医，试试看吧。

先看工程里有没有打印这个NPE吧，SLS日志搜了半天都没搜到，去源码看了一下，原来这里只打印了异常堆栈，那不会被采集到SLS中，不过服务器日志里可能会有。

妈耶还真给我搜到了，再仔细读了一下打堆栈的地方，会 将kotlin_error置为true，而且关键的地方在于这玩意儿是个static volatile变量！！ 具有静态共享特征（static）和多线程可见性（volatile），意味着整个工程使用的都是被修改后的值。

4. ☆ 锁定关键报错位置

继续进QuestionCardProxyApi 228行找到报错源，发现确实有个toJsonString。对于invokeResumeReq这个对象，我一眼看到有个古怪的赋值， this.resumeBody被赋值为{} 。但这个赋值有何神奇之处，哪能这么个小玩意儿导致全局异常啊？？

这段日志代码是12-17添加的，时间看了下还挺符合。再看resumeBody其实是个Java类的一个object类型字段，kotlin中这样对其赋值， 编译器倒也没报错 。

其实到这个地方已经感觉要水落石出了，再一看master，妈耶这个代码上线了，但线上却没有任何报错，运行一切正常。

但基本能确定是这里无疑了，就赶紧拉写这段代码的同学看（悄悄说，仁兄一开始提给我的bug），确认线上还没开始灰度，无任何流量后放心了。他在家里加班修，我继续看原理。

首先肯定 本意是想将resumeBody置空，误用了{}，{}在kotlin中被编译器解释为一个lambda表达式。

再看debug信息，这里resumeBody实际上被解释为 ()->kotlin.Unit 这样一个lambda函数，arity表示函数的参数数量为0.

也就是说： {}是一个没有任何入参，并且返回值默认为Unit类型的一个函数（没有明确返回值时默认Unit类型）。

为了更清晰地了解这个语法，可以看下面这个例子：这里定义了一个函数式变量x，入参为s，出参为s+“000”。在使用时可以直接以函数的方式调用x，最终得到y=111000

FastJson自然无法正确解析这样的一个Object字段，而最令人细思极恐的问题是解析这个对象报了错，却把kotlin_error置为true ，而后有没有地方将其复原为false，导致所有的反序列化都进到这里，返回不正确的结果，错误结果被外层拦截抛出default constructor not found异常。这个影响面是巨大的，会导致整个工程崩溃。

具体代码解释：

1. 一开始 kotlin_error !=true ，会进到 kotlin_kclass_getConstructors.invoke 获取类构造器，这里抛错了，把kotlin_error改为true；

2. 往后所有相关的FastJson序列化、反序列化重新进到这里都会return null，导致类构造器获取失败；

3. 外层没拿到paramNames，直接抛了异常。