Socket连接错误之toString() unavailable - no suspended threads

nnd，真想骂街。。。

最近公司新搞了一个项目，我负责在原来的app的基础上，改一下新的ip和端口，对新项目进行测试。本来是一个好好地app，跟服务器的socket连接啥的也都是嗖嗖的，结果，今天下午换到这个项目上一试，死活收不到服务器返回的数据，我又重新连到原来项目的IP和端口，一切正常啊。。。之后就是各种仔细查，单步调试我的app代码，完全没问题。后来调到br.readLine()这一行，（这个br：

                       // 输入流
InputStream is = socket.getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(is));）也就是读取服务器返回数据这一行，发现其实是接收到服务器返回的数据的，只是不知道为啥一直没办法结束接收这个过程，所以才导致一直没办法显示。并且在调试界面看到此刻显示的错误提示为：“toString() unavailable - no suspended threads”。然后就针对这个错误百度，之后查到这一篇博客：http://blog.csdn.net/u010148865/article/details/51473015

里面有着一段话：

代码一运行没有报错，输入流和输出流之间形成了死锁。由于client端的输出流没有告诉server端流已经结束，所以server端在等待client端的输出流，而client在等待server端的响应输出流，server端没有结束接收client端的输出,server也不会响应消息给client端。所以造成了死锁的现象。

用debugger模式可以看到server端的输入流出现这个提示：toString() unavailable - no suspended threads

我们在client端输出结束后加上这么一句：socket.shutdownOutput();就可以告诉server端，流已经结束。

我的错误跟上面的错误其实是异曲同工的，只是。。。这个真不是我的错误啊，分明是服务器那边代码挖的坑啊。。。

我意识到这个错误的原因是因为socket一直没有结束，所以才导致br一直处于接收状态。

但是我的app代码是明确断开了socket的：socket.shutdownOutput();

所以 ，问题肯定出现在服务器那一端。然而，此时写服务器那边的人，比我高一级，竟然在等着我来还这个错误。。。然后我就从服务器下载下来两个项目的代码，对比发现，新的项目缺少了一行最关键的代码：socket.close()

然后我默默的添加上了这一行。。。运行app之后，果然一切正常。。。欲哭无泪，这一个小问题搞了我一下午。。。

更坑的还在后面，我累死累活的改好了这个不属于我的错误的错误，给人家汇报了，结果人家测试之后，还说我对问题处理了么，怎么逻辑不对了。。。我的天，app只是负责发送接收消息而已，我这么闲还处理一下啊。。。关键是这个问题，我虽然没有参与但是用半个脑子想想都知道问题出在哪。。。作为算法核心开发人员竟然来问我。。。呵呵哒了。。。