java - 套接字绑定(bind)错误

Question

我有一个测试应用程序，它打开一个套接字，通过这个套接字发送一些东西，然后关闭它。这是在循环中完成 5-10.000 次。问题是，在 3,4000 次迭代之后，我得到了这种类型的错误:

java.net.BindException: Address already in use: connect

我什至设置了立即使用套接字，但错误仍然存​​在

try
{
     out_server.write(m.ToByteArray());
     socket_server.setReuseAddress(true);
     socket_server.close();
}
catch(Exception e)
{
     e.printStackTrace();
     System.out.println(i+" unable to register with the server");
}

我该怎么做才能解决这个问题？

Answer 1

我觉得你可能走得太快了。

大多数操作系统对它们在任何时候可以打开的套接字数量都有限制，但实际上比这更糟。

当套接字关闭时，它会在一定时间内处于特殊的时间等待状态。这通常是数据包生存时间值的两倍，它确保网络中没有数据包正在前往您的套接字的途中。

一旦该时间到期，您可以确定网络中的所有数据包都已死亡。套接字处于这种特殊状态，这样当您关闭它时网络中的数据包就可以被捕获并丢弃，如果它们在死亡之前到达。

我认为这就是您的情况，套接字没有像您想象的那样快速释放。

我们在打开大量短期 session 的代码中遇到了类似的问题。有一段时间它运行良好，但随后硬件变得更快，允许在给定时间段内打开更多。这表现为无法打开更多 session 。

检查这一点的一种方法是从命令行执行 netstat -a 并查看实际有多少 session 处于等待状态。

如果确实是这种情况，有几种方法可以处理。

• 手动或通过维护连接池重新使用您的 session 。
• 在每个连接中引入延迟以尝试停止达到饱和点。
• 全力以赴，直到达到饱和，然后修改您的行为，例如在 while 语句中运行您的连接逻辑，该语句最多重试 60 次，每次延迟两秒，然后再给出完全起来。这让您可以全速运行，只有在出现问题时才会减速。

---

最后一个要点值得扩展。实际上，我们在上述应用程序中使用了退避策略，如果资源提供者提示，它会逐渐减轻负载，而不是 30 两秒延迟，我们选择一秒延迟，然后两秒，然后是四个，依此类推。

回退策略的一般过程如下，它可以用于任何可能存在资源暂时短缺的情况。下面的伪代码中提到的操作是在您的情况下打开套接字。

set maxdelay to 16 # maximum time period between attempts
set maxtries to 10 # maximum attempts

set delay to 0
set tries to 0
while more actions needed:
    if delay is not 0:
        sleep delay
    attempt action
    if action failed:
        add 1 to tries
        if tries is greater than maxtries:
           exit with permanent error
        if delay is 0:
            set delay to 1
        else:
            double delay
            if delay is greater than maxdelay:
                set delay to maxdelay
    else:
        set delay to 0
        set tries to 0

这允许进程在绝大多数情况下全速运行，但在错误开始出现时退出，希望给资源提供者时间来恢复。延迟的逐渐增加允许更严重的资源限制来恢复，并且最大 try catch 您称之为永久性错误(或恢复时间太长的错误)。