在实际的thrift使用过程中，thrift客户端跟服务端通讯会有时爆出org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe异常，复现概率不高，很是困惑不知道是由什么原因引起的，在此记录一下分析和定位的过程，以备查看。
环境：
-centos 7
-jdk1.7
-thrift 0.9.1
-连接管理使用的对象池
问题产生的原因
这个异常产生的原因为thrift客户端向一个已经关闭的socket，写入数据导致该异常发生，在我们的客户端表现为client从对象池获取一个TCP长连接，然后在这个长连接上给服务端发送校验，校验连接是否存活，在实际写入探测字符串的时候，该异常发生，由TIOStreamTransport类在flush的时候抛出，关健的问题点在于客户端向一个已经关闭的socket做写入操作。
这里让我们推测一下，首先该连接已经在服务器端被服务器端显示关闭了，而客户端无法感知该连接已经被关闭，为什么服务器端会将这个连接关闭掉呢？原因有很多，例如：
服务器keeplive心跳，检测发现客户端存活，但是网络不可达，服务器就会关闭这个连接
连接由于其他原因，例如socket传输异常，导致服务器将这个连接关闭
我们初步怀疑是第一种原因导致的，因为在这个问题发生时，我们的客户端所在的服务还在正常运行。
下面我来看问题发生时的现象。
客户端截图： 
根据图中，我们明显看到客户端处于CLOSE-WAIT状态，而根据TCP状态图，我们知道进入这个是个状态是由于被动关闭导致的，也就是说我们对应的thrift服务器端将这个socket连接关闭了，而服务器端会进入FIN-WAIT2/TIME-WAIT和CLOSED，这里我们把TCP交互图列举出来： 
服务端TCP状况截图：
通过截图，我们可以很清楚的看到服务端已经将这个连接关闭了，这也就印证了我们的猜测，是由服务器端主动关闭了连接，导致了该问题发生
thrift探究
既然这个问题是由于thrift上报上来的，我们就去探寻一下thrift客户端的机制，看它是否能感知。通过源码分析得知（源码很多，就不具体列举了）thrift客户端是被动调用，由用户在需要的时候显示调用，进行RPC通讯，写入数据，然后读取返回值，这样就导致，即使服务端给客户端发送了fin挥手信息，他也不能处理，这样也就无法有效将这个连接关闭掉，而是由对象池在实际使用中进行检测，关闭这个失效的连接，对象池也只是管理了这个socket句柄，并没有对FIN的处理。
在thrift服务器端，我们分析查看了源码，发现，服务器端也没有针对长连接长时间不适用的应用程序的超时控制
结论
经过上文排查，基本怀疑是socket异常导致内核主动关闭连接或者心跳检测异常关闭连接，后续会针对这两种情况进行试验验证