java socket 判断关闭_如何判断Socket已经关闭

引子

前段时间我们的服务由于一台交换机网络出现故障，导致数据库连接不上，但是在数据库的连接超时参数设置不合理，connect timeout设置的过长，导致接口耗时增加。DB连接超时后线程未正常结束，上游请求又持续进来，最终耗光了Java线程，JVM进入持续GC状态，无法恢复，直到手工重启才恢复服务。

于是在服务的保护方面新增了两个措施，第一，调小服务端workThread的最大线程数。第二，在Server端设置Accept后Socket的readTimeout时间，当Socket调用read方法后在一定时间内读不到数据的时候会自动关闭socket。

说了这么多背景，但是本篇描述的不是这两个问题，而是我们上线了保护措施后遇到的奇怪的问题。

我们上线了这两个保护措施后，上游调用方向我们报异常，说请求总是返回错误，表现的情形为Socket的InputStream的read方法返回-1。

对方一口咬定是我们的问题，因为发送已经成功了，发送时候没有报任何异常，然而读消息的时候就返回-1了。

猜测应该是复用了已超时的连接所导致的，询问了一下，发现对方果然使用了连接池，而且这条业务线请求量比较小，所以极有可能是连接池中的socket其实已经在服务端被超时关闭了，所以调用服务的时候会发生异常，可是为什么发送的时候不会报错呢？而是在读结果的时候发现连接关闭了呢？

Flush？

首先很容易想到的是有一个时间差。对方正在发送的时候，socket并还没有被关闭，但是这些发送的内容在网络传输过程中的时候，服务端这边把socket给关闭了，所以出现了上文所描述的问题。对于rpc调用来说，一旦涉及到网络的，都可以认为时间间隔是完全随机的值，这种情形也是能解释得通。

但是，上游反馈这个异常非常的多，而且所有的都是同一个异常，读操作时候报错，连接已关闭。如果是上文中的情形才出现，那么首先这种错误应该比较少，而且绝大多数应该都是写出错，而不是读出错。

socket.getOutputStream.flush()返回成功到底是一个什么样的行为