前一阵子配合一个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