公司某业务出现严重的线上故障，复盘发现原因竟是某接口的Thrift IDL变更，未及时同步所有上游，导致上游某服务OOM引发Crash。看似操作不规范是本次故障的根因，但进一步思考：该接口非主流程接口，即使IDL版本不统一，带来“最坏”的后果不应该是“仅仅报错”吗，为什么会产生OOM导致整个服务Crash？

实际上这样的例子并不少见，很多公司内部RPC使用Thrift协议，IDL变更及版本不一致在所难免，极端情况下，安全团队扫描thrift端口也会出现类似故障。为了避免更多团队采坑，有必要研究Thrift何种情况下会触发，以及为什么会触发OOM。

一. 从IDL的字段变更说起

化繁为简，该故障的发生可以这样描述：某Thrift服务的返回值是一个数组，数组中每个元素本来包含5个字段，某次调整后，在中间位置新增1个字段，其余保持不变。服务上线后，某上游调用方未收到变更通知，仍使用旧版本的SDK。参照下图所示：

看到这里，有经验的同学已经瑟瑟发抖。在Thrift协议跨语言、高性能的背后，做了很多取舍，比如接收方在反序列化时，仅做了方法名等少量的校验，通过序号、字段类型认为该返回值属于哪个字段，而并未校验字段名，因此一旦上下游IDL版本不一致，极易产生字段错位的情况。以上述IDL为例，id、image字段正确解析，而bg_image被错误解析为link、link被错误解析为title：

字段增加时，考虑到字段位置及新旧版本不匹配的各种场景，我们枚举可能的后果：

新增字段放到中间位置
A. 新Server、旧Client：容易字段错位，引发业务错误，不推荐
B. 旧Server、新Client：容易字段错位，引发业务错误，不推荐
新增字段放到最后，并且是required
A. 新Server、旧Client：旧Client感知不到新增字段，会忽略
B. 旧Server、新Client：新Client获取不到新增字段，会报错
新增字段放到最后，并且是optional
A. 新Server、旧Client：旧Client感知不到新增字段，会忽略
B. 旧Server、新Client：新Client获取不到新增Optional字段，会忽略

再进一步，如果是删除字段呢？从删除字段的位置、是否required，大家可自行思考，当然结果类似，轻则被忽略，重则字段错位，当然更严重的会导致服务OOM。
小结：Thrift IDL不要变更已有字段的序列号，上下游版本不一致极易发生错位现象。如需新增字段，应放到最后并设置为optional。

二. OOM问题复现

回到IDL变更上来，为什么会引发上游服务的OOM呢？我们用一段很短的IDL就可以重现。

namespace java  com.didiglobal.thrift.sample
struct Items{
      1:required i64 id;
      2:required list<Item> items;
}
struct Item {
     1:required string name;
     2:required string image; // 新增字段
     3:required list<string> contents;
}
 
service Sample {
     Items getItems(1:i64 id);
}

如果你也想尝试，可以下载项目代码，在本地搭建环境。

Github下载项目代码：https://github.com/aqingsao/thrift-oom
使用你喜欢的IDE导入工程，该项目基于thrift 0.11.0版本，依赖JDK1.8+以及Maven
运行包com.didiglobal.thrift.sample1.sampleold中OldClientNewServerTest.java类的这个测试用例：oldclient_should_oom_at_concurrency_10
该测试用例会启动一个简单的Thrift服务，客户端使用10个并发，很快触发OOM（如果遇到问题，可联系作者）。

使用不同的Thrift版本，0.9.3到最新的0.13.0-snapshot均可以重现。使用jmap命令，可以看到应用创建了大量的字节数组。

小结：只需要10个并发就可以重现OOM，该问题广泛存在于Thrift 版本0.9.3到最新的0.13.0-snapshot。

三. 为什么会OOM？

本次故障的根因是新增String字段，并且客户端进程创建了大量的字节数组，首先怀疑字段错位后Thrift未正确处理，但查看了下源码，thrift对字段类型不匹配、多余字段均作了skip处理：

查看skip方法的实现，一度怀疑在类型为String时调用了错误的方法，但考虑String使用字节流传输，下图中直接调用readBinary()方法也无不妥，测试后发现也不是该问题：

思考了几个其他方向，并做了多次尝试，均发现思路不对，而且始终无法解释的是，单个请求数据量只有上百字节，为什么只需要10个并发、几十个请求就会OOM？这些请求的数据量累加起来也不过几十K，一度陷入僵局。

下班的路上反复思考，是不是和Thrift抛出的异常有关，恰遇某个路口超长时间的红灯，每每感叹该路口浪费多少青春年华，此时却从容拿出电脑，对Thrift抛出的异常做了临时处理，运行测试，果然不再OOM了！

思路一下子清晰起来：虽然Thrift做了多余字段的skip处理，但由于抛出的异常，这些skip操作并未执行到，甚至，List中第一个元素校验抛出异常后，后面所有字段都未继续消费！

按该思路重新阅读相关代码，果然找到了可疑点：Thrift接受服务端响应时，会首先解析TMessage对象，前4个字节（I32）代表了某个字符串的长度，后面readStringBody()方法会分配该长度的字节数组（byte[] buf = new byte[size]），该字符串实际上是thrift的方法名，而debug发现，长度值是184549632，大约176M，这合理解释了为什么10个并发就会触发OOM。

小结：Thrift接收到请求后首先读取TMessage结构，IDL版本不一致的极端情况下，会分配176M的内存空间，导致10个并发就占用上G内存，触发OOM。

四. 为什么会分配176兆的内存空间？

解决这个问题，有助于了解哪些场景下会触发OOM，从而更好地避免。

参考Thrift TServiceClient的receiveBase()方法，详细介绍了返回值的解析过程，参考下图可以更好地理解，基本上是一个从前到后类似堆栈的反序列化：

前面已经介绍过，如果返回值中多了参数、或者参数类型不对，Thrift可以通过skip()操作对该字段进行忽略。但thrift对struct结构体有个额外的操作，就是解析完成后的调用validate()方法，如果结构不合法，会抛出异常：

正常情况下，这里抛出异常，请求失败，应该关闭该连接，或者想重用连接的话，要先把底层Socket的输入流做清零处理。但Thrift未对输入流做任何处理，直接重用了该CLient实例及其底层的Socket连接，导致下一次解析响应数据时，读取的是上一次请求失败未处理完的数据。由于连接及底层Socket被重用，下一次发出请求，很快收到响应，Thrift惯例开始读取消息头：readMessageBegin→readI32()，由于存在未清空的脏数据，根据上图的堆栈分析，readI32()时读取的这4个字节，分别是：

byte type = TType.STRING; // 字节0：Item第一个字段(name)的类型，String，值为11
short id = 1; // 字节1和2：Item第一个字段(name)的位置，值为1
int size = 6; // 字节3：Item第一个字段(name)的size的首字节，值为6
byte（1个字节）+short（2个字节）+int（第1个字节），按big endian编码，其值恰好等于184549632：

小结：184549632的出现有其必然性，不恰当的IDL变更，Thrift客户端抛出异常后未做输入流清理，下一个请求会把之前的残留数据，错误解析成字符串大小，很快导致OOM。

五. 没遇到OOM，我是不是很幸运？

当然依IDL不同、异常抛出的位置不同，读取消息头时readI32()读取的数字不一定恰好是184549632。项目中提供了一个叫做sample2的IDL，旧Client访问新server时，该值的大小是8388864，大约等于8M，因此10个并发甚至100个并发也不一定会触发OOM。
所以当有不恰当的IDL变更，你没遇到OOM，只是幸运而已。

但进一步分析，这种情况虽不会触发OOM，但客户端一直等待服务端返回8388864个字节的数据，久等而不得，于是该连接被阻塞了，一直到超时。

小结：不恰当的IDL变更，不会全部导致OOM，也有可能导致大量连接被阻塞，直到超时错误。

六. 如何修复OOM?

参考Thrift themissing guide文档，IDL变更要有规范，并在团队内反复宣导。

讽刺的是，“通过规范、最佳实践来避免Crash类问题”，本身就不是一种最佳实践，至少使用Http协议不用遇到这种问题。

这可以认为是Thrift自身的一个缺陷，作为当前广泛使用的RPC协议，需要优雅地处理用户必须遇到的IDL变更的问题。

思路一：读取任何struct类型的字段时，catch住异常，保障thrift把输入流的所有数据读完
Thrift在反序列化阶段，遇到任何struct类型的字段，读取结束后都会调用validate()方法，因此在struct类型字段的读取时，可以添加try-catch校验异常，保证thrift读完所有的数据。

该思路经测试验证可以，但需要修改的地方较多，不具备可操作性。
思路二：无论是否抛出异常，从协议层面保证清空输入流的残留数据
该思路具备较好的收敛性，只需要修改Thrift源码的2个文件：TServiceClient修改如下图

1，TSocket类的修改如下图2：

经压测验证，在Macbook Air上，使用100个并发进行验证，持续15分钟，累计发送~160万次请求，单次请求响应数据量~0.5K，除了正常报错，客户端、服务端内存无任何异常。

小结：Thrift IDL变更不可避免，上下游版本不一致也不可避免，协议其实可以做到优雅地去处理，而不是OOM了事。

七. 有没有临时方案？

思路一：使用严格读模式？
Thrift众多的配置项中，有严格读（strictRead）、严格写(strictWrite)两个选项，由于严格读默认值为False，改为true是否可以呢？如果OK的话，只需要修改配置而无需修改源码，这将会是最轻量级的方案。查看Thrift源码，如果命中严格读会提前报错，避免下方readStringBody()方法分配太大的内存空间：

严格读（strictRead）的修改方式如下：
// 很多情况下大家如此使用TProtocol创建连接，此时strictWrite值为true，而、strictRead值为false；
TProtocol protocol = new TBinaryProtocol(transport);
// 严格读：直接创建TBinaryProtocol，传入参数
TProtocol protocol = new TBinaryProtocol(transport, true, true);
// 严格读：使用Protocol工厂模式，传入参数
TBinaryProtocol.Factory protFactory = new TBinaryProtocol.Factory(true, true);
经测试验证，使用严格读之后，客户端还会报错，但OOM问题消失了！“貌似”这也是我们想要的结果，压测效果如何呢？
在MacbookAir上，使用100个并发进行验证，5分钟之后，发送大约56万请求，客户端出现大量的SocketException(Broken pipe)，甚至客户端开始宕死。
究其原因，strictRead虽然避免了创建大量字节数组，但抛异常时thrift也未对输入流做任何清理，会产生误读取残余数据，甚至引起连接阻塞。
所以使用严格读，并不能解决这一问题，同样thrift提供了另外一个配置项“读取字符串或字节的最大长度（stringLengthLimit_）”，也不能解决该问题。

思路二：使用短连接？
每个请求创建一个短连接，用完就关闭？这样虽可以避免请求之间的数据污染，但毫无疑问也会带来较大的性能损失，通常不建议。

思路三：使用TFramedTransport？
TFramedTransport对整帧数据使用了缓存，一次性把底层Socket中Inputstream中的数据完全读到了readBuffer，理论上不会出现OOM了。
验证了一把，很可惜还是会OOM，原因是抛异常之后，TFramedTransport中的readBuffer中的数据未做清理，下次请求会错误读取readBuffer中的残余数据。
如果你想验证，可以运行OldClientNewServerTest中的测试用例：oldclient_should_oom_if_use_TFramedTransport_at_concurrency_10

小结：使用严格读、限制字符串长度等配置方式，使用TFramedTransport都不能完美解决问题，要么OOM，要么连接被阻塞。而短连接对性能影响较大，在Thrift中也很少使用。

八. 总结

Thrift IDL不恰当地变更，当上下游IDL版本不一致时，极易引发字段错位、连接阻塞、甚至OOM。Java、Go等语言实现中均存在该问题，并广泛存在于Thrift 0.9到最新的0.13.0-snapshot等各个版本。

该问题触发的根本原因是：客户端接收数据后，对struct类型做validate()时抛出异常，并未对底层的socket输入流做清零处理，后续请求误把残留数据读作字节长度，极易引发OOM，或者导致Socket连接阻塞超时。

Thrift IDL变更不可避免，上下游版本不一致也不可避免，从协议层面提供优雅支持是完全可能的。已向Thrift提交Issue，以及部分语言实现的Pull Request，但争吵几轮之后，Thrift维护人员拒绝合并，认为“遵守最佳实践就够了”，他们敷衍的态度太让人piss off了。

本文转载自技术锁话公众号。

原文链接：https://mp.weixin.qq.com/s/aqHoM7-hKQOFHRzWipfa8g

创作场景

一起变更引发的惨案