前一陣子配合一個ISV一直在查訪問TOP服務鏈接被重置的問題，當時認為是SDK的問題，因此我就將SDK的數據鏈路層代碼單獨剝離出來給ISV測試，沒有發現鏈接重置的問題。在加上部分業務代碼以后，有出現服務重置，但是概率很低。今天ISV同學給我發來了修改后的代碼（重置情況降低），這種修改還是有道理的，因此后續配合會升級SDK，這里也分享一下。（當時也考慮過這方面的問題，但是看了實現代碼覺得概率不大，但是可能也就是這點概率在網絡或者服務質量差的時候會被放大）
......
connection.getOutputStream().write(buffer.getBytes());
// 獲取鏈接的返回結果
TaobaoResponse response = new TaobaoResponse();
//獲取requestUrl與requestBody
response.setRequestUrl(connection.getURL().toString());
response.setRequestBody(buffer);
String systemParameters = connection.getURL().getQuery();
String appParameters = buffer;
setRequestParametersForResponse(response, systemParameters, appParameters);
String body = FetchUtil
.inputStreamToString(connection.getInputStream());
......
return response;
觀察 String body = FetchUtil.inputStreamToString(connection.getInputStream());的位置，其實在connection.getOutputStream().write(buffer.getBytes());這部已經將內容flush到服務端，此時由于沒有讀入輸入流，因此管道一直hold，做了很多和通信不相關的事情，但是這期間的時間還是會被算入在通信超時重置的時間內，因此將讀入數據流提前到發出請求以后，可以防止中間無關處理導致連接超時和鏈接重置的概率。這點在SDK中將改進，也提醒其他開發者，通信流程中避免無關的處理嵌入在通信事務中，降低信道利用率。對通信通道的快取快放能夠增加處理能力，業務處理可以另起線程單獨后續處理。
總結來說就是：對于瓶頸性資源（DB,Socket）等，在流程處理的時候盡量實現資源高效利用，業務相關操作非必要情況下脫離對瓶頸資源操作的事務。
這里特別感謝挖財365_淘帳本，給出了這些代碼修改的反饋，希望更多的開發者可以從使用者加入到參與者來。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/cenwenchu79/archive/2010/06/09/5658195.aspx