Что происходит, когда виртуальный поток выполняет блокирующий системный вызов? ⇐ JAVA

[Anonymous]

Я изучал, как работает Project Loom и какую пользу он может принести моей компании.
Итак, я понимаю мотивацию: для стандартного бэкэнда на основе сервлетов всегда существует пул потоков, который выполняет бизнес-логику, и как только поток блокируется из-за ввода-вывода, он не может ничего делать, кроме как ждать. Допустим, у меня есть серверное приложение с одной конечной точкой. Бизнес-логика этой конечной точки заключается в чтении некоторых данных с помощью JDBC, который внутренне использует InputStream, который снова будет использовать системный вызов блокировки (read() в терминах Linux). Итак, если у меня есть 200 сотен пользователей, достигающих этой конечной точки, мне нужно создать 200 потоков, каждый из которых ожидает ввода-вывода.
Теперь предположим, что я переключил пул потоков на использование вместо этого виртуальных потоков. По словам Бена Эванса в статье Внутри Java Project Loom и виртуальные потоки:

Вместо этого виртуальные потоки автоматически отказываются (или уступают) своему несущему потоку при выполнении блокирующего вызова (например, ввода-вывода).

Насколько я понимаю, если у меня есть количество ОС Потоки равны количеству ядер ЦП и неограниченному количеству виртуальных потоков, все потоки ОС по-прежнему будут ожидать ввода-вывода, а служба Executor не сможет назначать новую работу для виртуальных потоков, поскольку для ее выполнения нет доступных потоков. Чем он отличается от обычных потоков, по крайней мере для потоков ОС я могу масштабировать его до тысяч, чтобы увеличить пропускную способность. Или я просто неправильно понял вариант использования Loom? Заранее спасибо
Дополнение
Я только что прочитал этот список рассылки:

Виртуальные потоки любят блокировать ввод-вывод. Если потоку необходимо заблокировать, скажем, чтение сокета, то это освобождает базовый поток ядра для выполнения другой работы.

Я не уверен, что понимаю это, у ОС нет возможности освободить поток, если она выполняет блокирующий вызов, такой как чтение, для этих целей ядро ​​имеет неблокирующие системные вызовы, такие как epoll, который не блокирует поток и немедленно возвращает список файловых дескрипторов, которые имеют некоторые доступные данные. Означает ли приведенная выше цитата, что под капотом JVM заменит блокирующее чтение неблокирующим epoll, если поток, вызвавший его, является виртуальным?

Подробнее здесь: https://stackoverflow.com/questions/701 ... ystem-call