Socket.connect的連接超時有兩種情況:
1.由於網絡問題，TCP/IP三次握手時間>:超時的設置時間。在國外訪問微博，網絡環境極差時可能會出現這種情況。
解決方案:增加socket.connect方法中的超時參數值，例如50s。linux的默認最大值是70s。如果超過70s沒有意義，linux就采用70s。
但是，當它被打開時，如果發現它小於10s，它將被報告為超時異常。
通過用外國機器ping api.weibo.com來發現不可達。
說明客戶端在傳輸層以下的網絡層連Syn消息都發不了，更別說三次握手了，客戶端直接失敗拋出超時異常。
經驗:連接超時診斷第壹步應該是ping確認網絡層沒有問題。
註意:客戶端已經設置了超時，但是它不會等到超時才返回異常。只要客戶端第壹時間發現連接失敗，就會拋出超時異常。
2.如果超時設置了足夠的時間，但是服務器的處理能力差，比如緩沖連接隊列小，應用層的處理能力沒有連接緩沖快，導致緩沖連接滿，拒絕新的連接。
在服務器因連接隊列已滿而拒絕服務期間，客戶端通過TCP協議再次嘗試了三次。每次加倍時間。
如果三次的累積是
如果三次的累積是
1.讀寫超時
設置讀取超時是有意義的。在服務器處理能力差但最終會響應的情況下，可以將客戶端的等待時間設置得更長。如果太長，由於客戶端使用的是BIO方法，線程會壹直阻塞在IO中，導致掛起。當客戶端的處理能力明顯快於服務器時，就會出現很多掛起的線程。
無論客戶端還是服務器，當有很多線程阻塞時，都會影響機器的性能。在微博的論壇上看到有人在read超時後把soTimeout的時間設置為100s。這是非常危險的。新浪的服務器壹旦崩潰，自己的服務器也會因為大量線程而崩潰。
因為線程掛起後，它所擁有的資源，比如內存，是不會被釋放的，直到阻塞完成。同時，大量線程的暫停意味著系統必須恢復大量的上下文和調度執行。
解決方案:
如果客戶端使用NIO，並且服務器的響應可以標記客戶端的請求，那麽線程可以在客戶端請求之後將請求放入BlockQueue，然後使用Future或Wait/Notify等機制來回調隊列中的請求然後進行處理，從而實現異步處理，少量的線程可以服務大量的請求。
同樣，如果服務器可以使用NIO來處理每個線程的請求，而不是連接每個線程，就可以大大減少線程掛起造成的資源浪費。NIO適用於連接多，請求少的場合。另外，Commet也叫服務器推送技術，主要特點是長連接。避免客戶端低效的請求輪詢。主要用在聊天室，微博，因為連接多，不壹定請求多，也適合在服務器端使用NIO。
註意:讀取超時異常時，不需要ping遠程機器，因為是輔助位置連接超時。如果ping失敗，肯定是連接超時而不是讀取超時。讀取超時異常不會導致連接中斷。提供重試的機會。
2 .寫超時壹般不同於連接超時和讀超時，可以在客戶端顯示調優值。TCP有寫重傳的概念，會在8m內重試，否則直接斷開。
如果對妳有幫助，請采納。