Устраняют ли виртуальные потоки Java 21 основную причину перехода на реактивные однопоточные платформы?

Да, виртуальные потоки устраняют необходимость в реактивном подходе.

Потоки платформы в Java сопоставляются непосредственно с потоком операционной системы хоста потока. Эти потоки ОС «дорогие» с точки зрения памяти и процессора.

Виртуальные потоки, напротив, управляются внутри JVM. В результате виртуальные потоки чрезвычайно «дешевы», то есть достаточно эффективны как в памяти, так и в процессоре. Благодаря виртуальным потокам вы можете разумно рассчитывать на одновременное выполнение даже миллионов задач на обычном компьютерном оборудовании.

Да, большая часть, если не вся, работа, выполняемая в реактивном коде, может быть выполнена с помощью виртуальных потоков Java. Код гораздо проще писать, понимать, отслеживать и отлаживать. Реактивный подход был изобретен, чтобы обойти проблемы производительности, связанные с чрезмерным использованием потоков платформы.

Посмотрите видео , где Брайана Гетца спрашивают, каким он видит будущее реактивного программирования после появления Project Loom и виртуальных тредов:

Я думаю, что Loom убьет реактивное программирование… реактивное программирование было переходной технологией…

Отказ от реактивного программирования был одной из основных причин изобретения виртуальных потоков в Java.

Виртуальные потоки предназначены для блокировки кода.

Предостережение... Виртуальные потоки противопоказаны для задач, связанных с процессором , таких как кодирование/декодирование видео. Используйте виртуальные потоки только для кода, который включает блокировку, например ведение журналов, файловый ввод-вывод, доступ к базам данных, сетевые вызовы. Это охватит почти все бизнес-приложения Java.

Дешевые потоки могут выполнять дорогостоящие задачи

Конечно, задачи, выполняемые этими многочисленными дешевыми виртуальными потоками, могут потребовать значительных ресурсов. Эти ресурсы могут включать в себя потребление большого объема памяти, связывание ограниченного числа сетевых портов, перегрузку базы данных слишком большим количеством подключений и т. д.

В прежние времена Java-программисты узнали, что небольшое количество потоков платформы, которые были практичны для многопоточности, косвенно ограничивало чрезмерное использование ресурсов выполняющимися задачами. Теперь, когда потенциально существуют миллионы виртуальных потоков, вам может потребоваться добавить явное регулирование дорогостоящих задач для экономии драгоценных ресурсов. Вы можете использовать механизмы регулирования, такие как разрешения Semaphore или ReentrantLock.

Подробнее см. Ответ Тедди.

Закрепление

Слабость текущей реализации виртуальных потоков заключается в том, что в некоторых случаях виртуальный поток «прикреплен» к потоку своей несущей платформы, то есть его нельзя отложить, пока он заблокирован, для назначения этому потоку несущей платформы другого виртуального потока.

Начиная с Java 22, закрепление происходит как минимум в двух сценариях:

• synchronizedкод.
• Собственный код , вызываемый с помощью такого механизма, как JNI.

Чтобы внести ясность: вы можете использовать synchronized и собственный код в своих виртуальных потоках. Но если выполняемая задача включает в себя значительно длительные периоды такой работы, то назначьте эту задачу потоку платформы, а не виртуальным потокам. Или, в случае длинного кода, защищенного synchronized (долгодействующий код, а не весь код), замените на ReentrantLock. Чрезмерное закрепление снижает эффективность и результативность использования других виртуальных потоков.

Команда Project Loom продолжает свою работу. Они ищут способы уменьшить количество ситуаций, приводящих к закреплению. Так что ситуация может измениться в будущих версиях Java.

Вы можете легко обнаружить длительное закрепление. Java будет генерировать новое событие JDK Flight Recorder (JFR), jdk.VirtualThreadPinned каждый раз, когда закрепляется виртуальный поток, с порогом 20 мс по умолчанию.

Для получения дополнительной информации

Подробности см. в первую очередь в официальном документе JEP 444: Виртуальные потоки . См. также официальный сайт Project Loom.

Затем посмотрите недавние видео презентаций Рона Пресслера, Алана Бейтмана или Хосе Полара. В публичном доступе на YouTube и т. д.

Если вы действительно хотите понять, как был достигнут впечатляющий прирост производительности, посмотрите выступление Рона Пресслера на Продолжения : Продолжения - Под обложками. Чтобы внести ясность: это понимание совершенно необязательно и необязательно для эффективного использования виртуальных потоков. Но если вам нужно удовлетворить свое компьютерное любопытство, вам понравится именно эта речь Пресслера.

Виртуальные потоки устраняют большинство проблем с тяжелыми потоками ОС, которые решало реактивное программирование.

Однако с помощью виртуальных потоков вы все равно можете перегрузить целевые ресурсы.

Когда у нас было всего от 500 до 2000 потоков, мы создавали пулы потоков для веб-запросов и т. д., поэтому регулирование осуществлялось прямо в точке входа.

Теперь, когда мы вообще не регулируемся в точке входа (скажем, веб-сервер использует новую модель виртуального потока для каждого запроса), тогда все запросы теперь будут проходить через систему и попадать в БД или файловый ввод-вывод или Сторонний сервис.

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

То же самое относится и к процессору. Несколько задач, связанных с ЦП, все еще могут перегружать ЦП и припарковать 10 000 виртуальных потоков.

Таким образом, регулирование каждого ресурса должно осуществляться более осознанно.

Устраняют ли виртуальные потоки причину перехода на другую парадигму [например, реактивную]

Теоретически да, это намерение, но реальность слишком сложна, чтобы дать простой ответ. Исследование, проведенное Дэниелом О в его статье на DZone Демистификация производительности виртуальных потоков: раскрытие истины за пределами шумихи, показывает, что ничто, включая виртуальные потоки, не может превзойти производительность неблокирующего реактивного приложения, основанного на цикле событий.

Обратите внимание, что тесты включали не только операции с интенсивным использованием процессора , описанные выше , которые действительно не очень подходят для виртуальных потоков.

Такая разница в производительности вполне понятна: неблокирующая реактивная парадигма сводит к минимуму переключение контекста потока: либо полномасштабное, на основе ОС, либо облегченное, на основе виртуального потока/продолжения. Однако эта парадигма требует довольно строгого поведения, когда дело доходит до блокировки и неблокировки: реактивно-совместимый код должен быть полностью неблокирующим. Действительно, если только один метод в стеке выполнения не будет неблокирующим, то «одиночный» цикл событий застревает, и все приложение блокируется. Обратите внимание, что это требование применяется не только к коду, который пишет разработчик, но и к библиотекам, которые этот код использует. Вот почему для реактивного программирования требуются неблокирующие платформы и библиотеки, такие как веб-серверы, Netty или Helidon 3, Http-клиент, реактивные драйверы JDBC и так далее. Реактивное поведение драйвера JDBC настолько специфично, что Oracle, например, ввела специальные JDBC Reactive Extensions .

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

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

В общем, ваш вопрос слишком глубокий и сложный для ТАКОГО ответа и краткого последующего обсуждения и, ИМХО, заслуживает более детального исследования. Кроме того, легко увидеть, что в приведенном выше объяснении все понятия, такие как «цикл одного события», доведены до крайности, в то время как реальность намного сложнее. Например, в Netty есть не один, а «несколько» циклов событий, где «несколько», как всегда, очень свободно определено. «Полностью» неблокирующийся код — еще один хороший пример.