四. 为什么会分配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()方法分配太大的内存空间：
// 很多情况下大家如此使用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了。
所以当前最好的办法是，在团队内部反复宣导：Thrift IDL变更要遵守规范，尤其不要更改已有字段的序列号，任何变更记得通知调用方，以及Thrift themissing guide里面的更多内容。
作者介绍：张晓庆，滴滴高级技术专家，目前主要从事压测、容量管理方向的工作，您可以通过微信aqignsao916或者GitHub联系他，https://github.com/aqingsao
往期推荐
