如上圖，客戶端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一次。（實測後性能並沒有變化，不過也可能是壓力不夠。。）
