java - Java NIO 的选择器如何在底层检查可用事件？

Question

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

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

在上一个问题中，有人指出Java NIO 的select() 机制比轮询每个套接字，并在每次通过队列后 hibernate 要好得多。我知道 select 在理论上是如何工作的，但我难以理解的主要事情如下:如果轮询不好且效率低下，select() 是如何在幕后进行的？

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

They both [select() and poll()] handle file descriptors in a linear way. The more descriptors you ask them to check, the slower they get. As soon as you go beyond perhaps a hundred file descriptors or so - of course depending on your CPU and hardware - you will start noticing that the mere waiting for file descriptor activity and the following checking which file descriptor that it was, takes a significant time and becomes a bottle neck.

Answer 1

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

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