Project Loom虚拟线程发起阻塞系统调用时的运行机制相关问询

我正在调研Project Loom的运行原理，以及它能为我所在的公司带来哪些收益。
我理解它的设计初衷：对于基于标准servlet的后端服务，通常会使用线程池执行业务逻辑，一旦线程因IO操作阻塞，就只能等待无法执行其他任务。假设我有一个仅提供单个接口的后端应用，该接口的业务逻辑是通过JDBC读取数据，JDBC内部使用InputStream，最终会调用Linux下的阻塞系统调用read()。如果有200个用户同时访问这个接口，我就需要创建200个线程，每个线程都在等待IO完成。
现在假设我将线程池切换为使用虚拟线程。根据Ben Evans在Going inside Java’s Project Loom and virtual threads一文中的表述：

与之相反，当发生诸如IO之类的阻塞调用时，虚拟线程会自动让出（即yield）它们的载体线程。
按照我的理解，如果我的OS线程数量等于CPU核心数，同时虚拟线程数量不受限，那所有OS线程还是会等待IO，Executor service无法为虚拟线程分配新的任务，因为没有可用的线程来执行。这和普通线程有什么区别呢？至少OS线程我可以扩容到上千个来提升吞吐量。还是说我对Loom的适用场景理解有误？提前感谢解答。

补充内容 #

我刚刚阅读了这篇邮件列表内容：

虚拟线程非常适合阻塞IO场景。如果线程需要在比如Socket read操作中阻塞，这会释放底层的内核线程来执行其他工作。
我对这点不太理解：如果线程执行read这类阻塞调用，OS没有办法释放线程，针对这类场景内核提供了epoll这类非阻塞系统调用，不会阻塞线程，会立即返回有可用数据的文件描述符列表。上面的引用内容是不是意味着，当调用阻塞read()的是虚拟线程时，JVM底层会将其替换为非阻塞的epoll调用？

你对Loom机制的理解存在两个核心偏差，下面直接对应解释实现逻辑：

为什么虚拟线程阻塞IO时不会卡住载体线程 #

你之前的假设前提「虚拟线程调用阻塞read会让载体线程执行阻塞系统调用」并不成立。
JDK中所有和阻塞IO相关的标准库API（包括Socket、InputStream、主流JDBC驱动等常用实现）都已经做了Loom适配：当虚拟线程调用这类阻塞方法时，JVM不会真的让当前载体线程去执行阻塞的系统调用，而是会把这个IO请求注册到JVM全局的异步IO调度器，底层依赖操作系统提供的epoll（Linux）、IOCP（Windows）等非阻塞多路复用机制实现，之后当前虚拟线程会直接挂起让出载体线程，载体线程可以立刻被分配给其他待运行的虚拟线程执行任务。
等到对应的IO事件就绪（比如read请求的数据已经到达内核缓冲区），调度器会把之前挂起的虚拟线程重新加入待执行队列，等有空闲载体线程时就恢复执行后续逻辑，全程载体线程不会出现OS层面的阻塞。
只有当你调用了未适配Loom的阻塞操作时（比如JNI代码中直接调用原生阻塞系统调用、使用未做虚拟线程适配的第三方Native库），才可能出现载体线程被OS阻塞的情况，这种场景下Loom会自动临时拉起新的载体线程处理其他待调度的虚拟线程，额外开销也远低于直接创建大量OS线程。

和普通OS线程的核心差异 #

普通OS线程的固有开销很高：每个线程默认栈空间至少1MB，且线程调度需要操作系统内核态完成，上下文切换成本极高，当线程数量达到数千级别时，光线程调度的CPU开销就会吃掉大量算力，吞吐量很难提升。
虚拟线程是JVM在用户态实现的轻量级调度单元，初始栈空间仅几百字节，调度完全由JVM在用户态完成，上下文切换成本比OS线程低一到两个数量级，即使创建百万级别的虚拟线程也不会有明显的内存和调度开销。
回到你举的200并发请求的场景：如果使用普通线程池，需要至少200个OS线程才能支撑，要是并发涨到2000就得对应扩容到2000个OS线程，开销会线性上涨；如果用虚拟线程，只需要保持和CPU核心数相等的载体线程（比如8核就用8个）即可，200甚至2000个请求对应的虚拟线程在IO阻塞时都会自动让出载体线程，8个载体线程全程可以处于满负荷运转状态，吞吐量会比普通线程池高几倍到几十倍不等。

关于是否替换为epoll调用的疑问 #

本质上你的理解是对的：上层代码调用的阻塞read()方法，在虚拟线程执行时，JVM底层确实会把它转换成基于epoll的非阻塞IO操作，而且这个转换对上层代码完全透明。你不需要改任何同步阻塞的业务代码，不需要写回调、不需要接入反应式框架，就能拿到和异步非阻塞架构相当的吞吐量，这也是Project Loom最核心的设计价值。

内容的提问来源于stack exchange，提问作者Almas Abdrazak