如上图，客户端close_wait，肯定是因为服务端发起了关闭操作。
服务端close，但是客户端没有close，所以客户端进入了close_wait的状态。这种情况一般出现在：提前创建了连接池，如果池子中的某些（或者全部）连接一段时间没有active，就会出现这种情况。这个时候如果再有读写操作，thrift则抛异常。
解决方案：
1.服务端修改idle_timeout的时间，设置的长一些，这样客户端进入close_wait的可能性会少一些。不太现实，毕竟服务使用方可能不是只有一方，而且长时间保持着连接，又没啥用，会造成服务端的资源浪费。
2.客户端咨询服务端设置的idle timeout时长后，设置一个last_access_time，使用前判断一下是否超过了服务端的keepalive时间，如果超过了，则close掉，重新链接一下。每次读写之后更新一下这个last_access_time。
3.心跳检测，告诉服务端客户端还活着。
4.简单粗暴一些的，每次访问前，重新open一次。（实测后性能并没有变化，不过也可能是压力不够。。）
