我正在尝试使用 nio 通道和选择器来了解 java 中的非阻塞 io，
这是我的理解，在每个请求线程模型中，每次侦听服务器套接字接受新连接时，都会创建一个新线程，并引用服务器套接字返回的新创建的客户端套接字，这个为每个连接新创建的线程是本质上是阻塞的，因为它只有在处理完之前收到的任何消息后才能接受新消息。
在非阻塞 io 中，特定连接的客户端通道最初是向选择器注册的，对读取操作感兴趣，一旦事件循环线程读取了消息，它就会将其发送到处理业务逻辑以进行进一步处理的线程池，并且通道被解除阻塞，它（eventloop）可以继续读取任何新消息（因此非阻塞），一旦业务逻辑线程完成执行，它指示选择器唤醒，然后eventloop线程变得活跃并将感兴趣的操作更改为写入对于该特定的客户端渠道，然后客户端最终会得到响应。
我的疑问是，在非阻塞 io 的情况下，我们依赖线程池来处理业务逻辑，所以我们不是间接地最终创建了与收到的消息一样多的线程。如果是这样，那么为什么使用 nio 比常规 io 更好。另外，如果线程池中的线程数量有限，那么当尝试提交到该线程池时，eventloop线程是否会被阻塞？
由于我是初学者，所以如果我所做的任何假设不正确，请指出。
连续的句子很难阅读，所以我可能无法回答你的问题。但使用非阻塞 I/O，单个线程可以等待多个连接上的数据可用性（通过选择器），与连接数量无关。
完成对特定连接的阅读后，您可以选择：
您可以立即将其交给线程来处理，在这种情况下，所需的线程数将等于“同时”到达的最大请求数。这可能会比连接数少很多。
您可以将请求排队以由线程池处理，并限制线程数。即，为了限制资源使用，您愿意注入一些延迟。
当然，还有更多内容，具体取决于处理请求所需的具体内容，但您应该明白了。