这涉及两个自动化单元测试，每个测试都启动一个 tcp/ip 服务器，该服务器创建一个非阻塞套接字，然后在 select() 上为连接和下载一些数据的客户端循环 bind()s 和 listen()s。
问题是它们在单独运行时运行良好，但是当作为测试套件运行时，第二个测试客户端将无法与 WSCONNREFUSED 连接......
除非
他们之间有几秒钟的 Thread.Sleep() ??!!!
有趣的是，在任何失败后，每 1 秒都会有一个重试循环用于连接。所以第二个测试循环了一段时间，直到 10 分钟后超时。
在此期间，netstat -na 显示服务器套接字的正确端口号处于 LISTEN 状态。那么如果它处于监听状态呢？为什么它不接受连接？
在代码中，有日志消息显示 select NEVER 甚至没有准备好读取套接字（这意味着当它应用于侦听套接字时准备好接受连接）。
显然，问题必须与完成一个测试之间的某种竞争条件有关，这意味着套接字每一端的 close() 和 shutdown()，以及下一个测试的启动。
如果重试逻辑允许它在几秒钟后最终连接，这不会那么糟糕。然而，它似乎被“搞砸了”，甚至不会重试。
然而，由于某种奇怪的原因，监听套接字说它处于 LISTEN 状态，即使一直拒绝连接。
所以这意味着实际上是 Windoze O/S 正在捕获 SYN 数据包并返回一个 RST 数据包（这意味着“连接被拒绝”）。
我唯一一次看到这个错误是当代码出现问题导致数百个套接字卡在 TIME_WAIT 状态时。但这里不是这样。netstat 在任何给定时刻仅显示大约十几个套接字，其中 TIME_WAIT 中只有 1 或 2 个。
请帮忙。