Java NIO 的选择器如何在后台检查可用事件？

Question

before 有人问过类似的问题，但我想再提出一次，希望有人能帮助解决一些问题。作为一个实验，我尝试在不使用 NIO 的情况下用 Java 编写一个简单的“非阻塞”服务器，其中基本上需要三个线程：

1. 主服务器线程 - accept()s 新套接字连接，并将每个新套接字放入队列中
2. 读取工作线程-遍历队列中的每个套接字，并从每个套接字的输入流中读取一点点，并将其存储在InputQueue
3. 编写工作线程 - 根据传入请求从每个套接字读取的时间，该工作线程将遍历所有需要响应的套接字，并再次在每次接收时写入几个字节的响应。

在上一个问题中指出，Java NIO 的select() 机制远比在每个socket 上轮询，并且在每次通过队列后休眠一点。我知道 select 理论上是如何工作的，但我难以理解的主要内容是：如果轮询不好且效率低下，select() 是如何在幕后做到的？

更新：我找到了this page，它更清楚地说明了原生select() 是如何工作的。有趣的是，确实，我最初的猜测似乎是正确的：select() 以线性方式工作，探测每个请求的文件描述符，类似于轮询机制所做的：

他们都 [select() 和 poll()] 在一个 线性方式。您要求他们检查的描述符越多，速度就越慢 他们得到。一旦超过一百个文件描述符 左右 - 当然取决于你的 CPU 和硬件 - 你会开始 注意到仅仅等待文件描述符活动和 在检查它是哪个文件描述符之后，需要一个 重要的时间并成为瓶颈。

Answer 1

它调用操作系统中的select()方法，它：

• 如果套接字接收缓冲区中有数据或 FIN，则认为套接字可读
• 如果套接字发送缓冲区中有空间（即大部分时间），则认为套接字是可写的。