Java 故障排除卡在关闭等待状态的连接

我有一个Java应用程序在Windows上的WebLogic11g中运行，几天后，它就没有响应了。我注意到的一个可疑症状是，即使在服务器空闲时，

netstat

中也会出现大量连接（约3000个），并处于关闭等待状态。因为应用服务器正在管理客户端连接，所以我不确定是什么原因导致了这种情况。我们还进行了大量的web服务调用，这些调用会回送到同一台服务器，但我相信这些连接会正确地关闭。还有什么原因会导致这种情况，人们如何解决这样的问题？

我找到了一句关于CLOSE_WAIT Pilleups的名言：“有什么东西阻碍了我们的进步。” 发生在HTTP会话中（我们被卡住了，因此永远不会调用close），或者引入了一些错误来阻止套接字关闭。这种情况有多种发生方式。”

思考：在处理请求时，您的应用程序是否有可能被卡住？还是WebLogic本身

检查：您是否可以执行Java线程转储（kill-SIGQUIT可用于Oracle JVM for Linux上的转储），以尝试查看您的线程是否被卡住

---

检查客户端：首先，找出连接到CLOSE_WAIT套接字的客户端的IP地址或主机名。然后，查看这些客户端上是否发生任何可疑事件。

关闭\u等待状态表示另一端已启动连接关闭，但本地端的应用程序尚未关闭套接字

---

听起来您的本地应用程序中有一个bug。

CLOSE\u WAIT

是远程主机发送FIN（关闭连接）但本地应用程序未执行相同操作并发送回复FIN时本地TCP状态机所处的状态。尽管客户端无法接收数据，但本地计算机仍有可能在此时发送数据（除非它在连接上只关闭了一半）

当远程主机关闭（发送FIN）时，您的本地应用程序将获得某种类型的事件（它是基本C库中套接字上的“读取”事件），但从该连接读取将返回一个错误，指示连接已关闭。此时，本地应用程序应关闭连接

---

我对Java知之甚少，对WebLogic一无所知，但我认为应用程序可能没有正确处理读取错误，因此从未关闭连接。

我也遇到过同样的问题，我一直在研究套接字以解决这个问题

让我说几句话，但在我必须说我不是Java程序员之前

我将不解释什么是密切等待，因为布赖恩·怀特已经说了所有应该说的话

为了避免close_wait，您需要确保服务器在发送回响应后不会关闭连接，因为首先断开连接的人会陷入close_wait和time_wait。因此，如果您的服务器卡在close_wait中，它会在发送响应后告诉我它正在断开连接

你应该通过做一些事情来避免这种情况

1-如果您的客户端应用程序未使用http 1.1协议，则必须将其设置为使用该协议，因为

“保持活动”

http头选项

2-如果您的客户端正在运行http 1.1，但无法正常工作，或者如果必须使用http 1.0，则应设置连接请求标头属性：

connection: keep-alive

这告诉服务器，在完成请求后，客户端和服务器都不应断开连接。这样，服务器就不会在收到每个请求后断开连接

3-在客户端中，重用套接字。例如，如果您在一个循环中创建了许多套接字客户端，那么您应该创建一次套接字，每次需要发送请求时，它们都会使用它。我在应用程序中使用的方法是拥有一个套接字池，并获得一个可用的套接字（该套接字已连接到服务器，并且具有keep-alive属性）。然后我使用它，当我完成后，我把它放回池中，以便重复使用

4-如果发送请求后确实需要断开连接，请确保您的客户端执行此操作，并保持

连接：保持活动状态

是的，当服务器端有大量的close_等待或time_等待时，您可能会遇到问题

请查看此[链接][1]，它解释了什么是
保持活动

我希望这是有帮助的。有了这些东西，我设法解决了我的问题

[1] ：Connections
问题是在webLogic中将“Use JSSE SSL”设置为true时触发的错误。使用WebLogic自己的SSL实现而不是JSSE对我们的应用程序来说不是问题，所以我只是取消选中该设置，问题就消失了。
这可能意味着您没有从accept（）调用套接字上的“close”呼叫。
您确定总是关闭服务器端的连接吗？它们是否显示为关闭？甚至在应用程序没有响应之前等待？@weekens-我不关闭服务器端的连接，WebLogic会@Robin-是的，在一个配置类似的服务器上，我看到连接在服务器崩溃之前积累。我认为您在回答中严重混淆了close_wait和time_wait。根据TCP FSM规范，这是不正确的。当服务器发送响应后断开连接时，不会发生CLOSE_WAIT。当客户端（另一端）启动TCP连接的终结时，服务器端的应用程序不会发出close（）sys调用（正如Brian White在此线程中所解释的）