Я изучал, как работает Project Loom и какую пользу он может принести моей компании.
Итак, я понимаю мотивацию: для стандартного бэкэнда на основе сервлетов всегда существует пул потоков, который выполняет бизнес-логику, и как только поток блокируется из-за ввода-вывода, он не может ничего делать, кроме как ждать. Допустим, у меня есть серверное приложение с одной конечной точкой. Бизнес-логика этой конечной точки заключается в чтении некоторых данных с помощью JDBC, который внутренне использует InputStream, который снова будет использовать системный вызов блокировки (read() в терминах Linux). Итак, если у меня есть 200 сотен пользователей, достигающих этой конечной точки, мне нужно создать 200 потоков, каждый из которых ожидает ввода-вывода.
Теперь предположим, что я переключил пул потоков на использование вместо этого виртуальных потоков. Согласно Бену Эвансу в статье Внутри Java Project Loom и виртуальные потоки:
Вместо этого виртуальные потоки автоматически отказываются (или уступают) свой поток-носитель при выполнении блокирующего вызова (например, ввода-вывода).
Насколько я понимаю, если у меня количество потоков ОС равно количеству ядер ЦП и не ограничено количества виртуальных потоков, все потоки ОС по-прежнему будут ожидать ввода-вывода, а служба Executor не сможет назначать новую работу виртуальным потокам, поскольку для ее выполнения нет доступных потоков. Чем он отличается от обычных потоков, по крайней мере для потоков ОС я могу масштабировать его до тысяч, чтобы увеличить пропускную способность. Или я просто неправильно понял вариант использования Loom? Заранее спасибо
Дополнение
Я только что прочитал этот список рассылки:
Виртуальные потоки любят блокировать ввод-вывод. Если потоку необходимо заблокировать, скажем, чтение сокета, тогда это освобождает базовый поток ядра для выполнения другой работы.
Я не уверен, что понимаю это, у ОС нет возможности освободить поток, если она выполняет блокирующий вызов, такой как чтение, для этих целей ядро имеет неблокирующие системные вызовы, такие как epoll, который не блокирует поток и немедленно возвращает список файловых дескрипторов, в которых есть некоторые доступные данные. Означает ли приведенная выше цитата, что под капотом JVM заменит блокирующее чтение неблокирующим epoll, если поток, вызвавший его, является виртуальным?
