thrift java线程安全_Thrift多线程误用惨案

Thrift个人觉得还是挺不错的一个rpc工具，相对而言比较容易上手。

其实断断续续接触thrift也有一年半了，没想到这次还是掉坑里了。由于之前大多是调用方情形，接触多线程下的thrift不多，也就是这不熟悉，导致了我一天的功夫全砸在了一个很低级的错误上面。

惨案背景：小文件存储系统基本功能开发完毕。控制器、系统对外接口、存储节点三大模块通过Thrift来进行跨机器远程通信。出于进行压力和并发测试的目的，写了个测试程序,多线程多线程同时进行文件存储。运行多次出现以下几点状况：

1、程序运行几十秒之后卡死

2、莫名滴偶尔有类似connection reset peer错误报出

3、程序崩溃

由于在存储节点端，对文件以及一些公共数据区域进行了加锁，总共四把，虽然用的都是局部锁，但毕竟不常用，心里对这个拿不准，加上程序运行卡死的现象，所以上来就往死锁的方面考虑。各种打印线程id和变量、跟踪程序等等。可是加锁前后区域输出均正常。无奈只好从最初起点传输端开始，逐步跟进。几经折腾，最后发现test_save函数中client->save(rsp,

req);前后均正常，但到在server端偶尔会出现接受数据为空的现象，并且出现为空之后整个系统也就进入卡死状态了。很诡异啊，就这一句rpc调用，client端调用前后正常，到server端就出现数据不一致现象。我性了你的邪，搞毛东东啊。还好接触对她thrift不算陌生，也就没有往怀疑其工具可用性的方向走，而是继续老实巴交滴review自己的代码。最后发现还是自己too

young too simple了。

原因：thrift

<