我已经阅读了很多材料来尝试并清楚地了解Jetty Non Blocking Web应用程序服务器能够或不能提供的收益。
到目前为止，我所理解的（部分通过引用：How do Jetty and other containers leverage NIO while sticking to the Servlet specification?）是使用非阻塞IO模型，像Jetty这样的Web服务器运行单个（或每个CPU核心一个）线程 - Selector线程 - 确定为某些I / O做好准备的连接。将调度与某些I / O准备就绪的连接以便处理到内部线程池以处理请求。
我可以看到这样的架构如何允许您以更少的资源提供更多连接。但是，我不清楚的是：
如果我使用执行阻塞I / O的标准JDBC驱动程序编写了一个运行长时间运行的数据库操作的servlet，那么从池中调度的处理程序线程不会处理此请求块吗？
如果请求的执行速度快于数据库请求，那么处理程序线程池会在某些时候耗尽吗？
所以使用这样的应用程序在Non Blocking Jetty网络服务器上运行有什么好处？如果servlet本身使用了另一层对数据库的非阻塞访问，那么非阻塞优势是否真正累积？还是有什么我想念的？
请解释一下，如果Jetty为阻塞数据库操作支付的价格低于拦截网络服务器，那么是否有一些神奇之处。
PS：关于对比，我在这里读到了Node.js - How the single threaded non blocking IO model works in Node.js - 它似乎暗示Node使用下面的libuv并应用其他技术来翻译代码中的所有阻塞操作（例如数据库访问和{{ 1}}）进入事件回调，确保事件循环和内部线程池永远不会在阻塞回调中被阻止。虽然它对我来说仍然有点小麻烦，但假设对于Node来说是真的，Jetty可以保证一样吗？对于那些不是以非阻塞方式编写的servlet等也是如此？