关于Java ServerSocket Accept：忙着等待？

Question

我正在阅读Java中的TCP/IP套接字，关于服务器套接字，它说

当我们在该ServerSocket实例上调用接受（）时，如果新连接挂起，接受（）立即返回；否则它会阻塞，直到连接进入或计时器到期，以先到者为准。这允许单个线程处理多个连接。不幸的是，这种方法要求我们不断轮询所有I/O源，而这种“忙等待”方法再次引入了大量开销，因为循环遍历连接只是为了发现它们无事可做。

据我所知，当连接到来时，是否应该“通知”，因此不应该“忙于等待”？我误解了什么吗...？

-----------------编辑----------------------

整段内容如下：

由于这些复杂性，一些程序员更喜欢使用单线程方法，在这种方法中，服务器只有一个线程，它不按顺序处理所有客户机，而是同时处理所有客户机。这样的服务器无法承受任何一个客户端的I/O操作阻塞，必须专门使用非阻塞I/O。回想一下，对于非阻塞I/O，我们指定了对I/O方法的调用可能阻塞的最大时间量（包括零）。我们在第4章中看到了一个例子，我们在接受操作上设置了超时（通过ServerSocket的setSoTimeout（）方法）。当我们在该ServerSocket实例上调用accept（）时，如果新连接挂起，accept（）立即返回；否则，它会阻塞，直到连接进入或计时器过期，以先到者为准。这允许单个线程处理多个连接。不幸的是，这种方法要求我们不断轮询所有输入/输出源，而这种“繁忙等待”方法再次引入了大量开销，因为循环连接只是为了发现它们与之无关

Answer 1

这几乎是胡说八道，即使是在整个引用中。要么您使用阻塞I/O，在这种情况下，每个连接需要一个线程，每个accept（）循环需要一个线程，要么您使用非阻塞I/O，在这种情况下，您有select（），或者，从Java 7中，您使用异步I/O，在这种情况下，它都是对完成处理程序的回调。在这些情况下，您都不需要投票或忙于等待。

我想他一定是指使用阻塞模式，超时时间很短，但这确实是最不清楚的。