我在尝试从套接字读取时遇到以下错误。我正在对该InputStream执行readInt()操作，但是出现了这个错误。查阅文档后发现，连接的客户端部分关闭了连接。在这种情况下，我是服务器。
我可以访问客户端日志文件，它没有关闭连接，并且其日志文件表明我正在关闭连接。那么有人知道为什么会发生这种情况吗？还有什么其他要检查的？当本地资源可能达到阈值时是否会出现这种情况？
我注意到我有以下这行代码：
socket.setSoTimeout(10000);
就在readInt()之前。有一个原因（长故事），但只是好奇，是否存在导致指定错误的情况？我在我的IDE中运行服务器，并且碰巧将我的IDE卡在断点上，然后我注意到我的日志中开始出现完全相同的错误。
总之，只是提一下，希望不是一个错误的提示。
可能有几种原因。
另一端故意以我不会在此说明的方式重置了连接。对于应用软件来说，这是罕见且通常不正确的做法，但商业软件并非未知之事。
更常见的原因是向已经正常关闭的连接写入数据。换句话说，这是应用程序协议错误。
当套接字接收缓冲区中仍有未读数据时关闭套接字也可能导致此问题。
在Windows中，“软件导致连接中止”（与“连接重置”不同）是由您的端发送网络问题引起的。Microsoft有一篇知识库文章介绍了这个问题。
连接重置是指收到了TCP RST。这种情况发生在您的对等方接收到无法处理的数据时，可能有多种原因。
最简单的情况是当您关闭套接字（socket）后，在输出流上写入更多数据。通过关闭套接字，您告诉对等方您已经结束通话，并且它可以忘记您的连接。但是，当您在该流上发送更多数据时，对等方会拒绝并用RST通知您它不再监听。
另外，在某些情况下，作为中介的防火墙甚至远程主机本身可能会“忘记”您的TCP连接。如果长时间不发送任何数据（2小时是常见的超时时间），或者因为对等方重新启动并且丢失其关于活动连接的信息，则可能会发生这种情况。在这些失效的连接中发送数据也会导致RST。
根据额外的信息更新：
仔细检查您处理SocketTimeoutException的方式。如果在套接字操作被阻塞时超过了配置的超时时间，则会引发此异常。当抛出此异常时，套接字本身的状态不会改变，但是如果您的异常处理程序关闭套接字，然后尝试向其写入数据，则会导致连接重置的情况。 setSoTimeout()旨在为您提供一种干净的方式来打破可能永远阻塞的read()操作，而不必像从另一个线程中关闭套接字这样做危险的操作。
你应该非常仔细地检查完整的跟踪记录，
我有一个服务器套接字应用程序，并解决了java.net.SocketException：连接重置的问题。
在我的情况下，它发生在从关闭其连接的客户端 Socket 对象读取时，原因可能是网络中断、防火墙或应用程序崩溃或意外关闭。
实际上，当我从此 Socket 对象读取时遇到错误时，我正在重新建立连接。
Socket clientSocket = ServerSocket.accept();
is = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
int readed = is.read(); // WHERE ERROR STARTS !!!
有趣的是，对于我的JAVA Socket，如果客户端连接到我的ServerSocket并关闭其连接而不发送任何内容，则会重复调用is.read()。看起来由于在无限循环中从此套接字读取数据，您尝试从已关闭的连接读取数据。
如果您使用以下代码进行读取操作;
while(true)
{
Receive();
}
然后你会得到一个类似下面的堆栈跟踪信息
java.net.SocketException: Socket is closed
at java.net.ServerSocket.accept(ServerSocket.java:494)
我所做的就是关闭ServerSocket，重新建立连接并等待进一步的客户端连接。
String Receive() throws Exception
{
try {
int readed = is.read();
....
}catch(Exception e)
{
tryReConnect();
logit(); //etc
}
//...
}
这可以重新建立我的连接，以解决未知客户端套接字的丢失问题。
private void tryReConnect()
{
try
{
ServerSocket.close();
//empty my old lost connection and let it get by garbage col. immediately
clientSocket=null;
System.gc();
//Wait a new client Socket connection and address this to my local variable
clientSocket= ServerSocket.accept(); // Waiting for another Connection
System.out.println("Connection established...");
}catch (Exception e) {
String message="ReConnect not successful "+e.getMessage();
logit();//etc...
}
}
由于您可以从下面的图像看到，如果没有使用try和catch， 您无法判断连接是否中断，因为一切似乎都是正确的，我无法找到其他方法。 我在不断收到Connection reset的同时获取了这个快照。
ESTABLISHED时，另一端观察到SYNC_SENT。在这种情况下，我们会重新启动整个应用程序。此外，如果线程在accept时被阻塞，它会被捕获并重新尝试，以全新的状态再次开始。这是我从7年前记得的。谢谢您的友善评论。 - undefined有些难为情，但当我遇到这个问题时，简单地说是我在读完所有数据之前关闭了连接。对于返回小字符串的情况，它可能能够正常工作，但这可能是因为整个响应已经被缓冲，然后我关闭了它。
对于返回大量文本的情况，由于返回的内容超过了缓冲区的大小，就会抛出异常。
您可能要检查这种疏忽。请记住，打开URL就像打开文件一样，确保在完全读取后关闭它（释放连接）。
我遇到了同样的错误。现在我已经找到了解决方法。问题是客户端程序在服务器读取流之前就结束了。
我曾经遇到过一个使用Java编写的SOA系统的问题。我将客户端和服务器运行在不同的物理机器上，它们长时间以来一直正常工作，但是当客户端日志中出现了连接重置时，在服务器日志中并没有发现任何异常。即使重新启动客户端和服务器也无法解决这个问题。最终我们发现服务器端的堆栈已经非常满了，因此我们增加了JVM可用的内存：问题解决了！请注意，日志中没有OutOfMemoryError：内存只是紧缺，而不是耗尽。
OutOfMemoryError 的内容。 - user207421-Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack
我通过将该功能推出到我们兼容JDK8的产品中来解决了这个问题，因为JDK8默认使用TLSv1.2。对于仍受限于JDK7的用户，我也成功地测试了一个解决方案，即升级到TLSv1.2。我使用了这个答案：How to enable TLS 1.2 in Java 7。