Реактивная весенняя загрузка с помощью сопрограмм Kotlin: Добавление виртуальных потоков

Эта сессия знаменует собой возвращение на YouTube-канал увлекательной дискуссии о Kotlin, продолженной на предыдущей встрече, состоявшейся два месяца назад. Зрителей приглашают принять участие, задавая вопросы в чате во время презентации. Ведущий будет следить за взаимодействием и отвечать на запросы по мере их возникновения, способствуя созданию интерактивной среды. Подписчикам настоятельно рекомендуется ставить лайки на контент и взаимодействовать с ним, чтобы повысить узнаваемость и поддержку энтузиастов Kotlin.

Опыт в разработке программного обеспечения: Путешествие по языкам Питер, старший инженер-программист и преподаватель Kotlin, делится своим обширным опытом в разработке программного обеспечения. Последние пять лет он перешел с Java на Scala и теперь специализируется исключительно на Kotlin. Его страсть - параллельное программирование на различных платформах, включая reactive streams и actor framework. Питер приглашает аудиторию принять участие, чтобы оценить их знакомство с Spring MVC, Spring WebFlux (реактивным), сопрограммами и виртуальными потоками.

Изучение интеграции сопрограмм и виртуальных потоков Цель занятия - изучить интеграцию сопрограмм с Spring Boot, а также повысить уровень знаний аудитории об этих технологиях. Питер поощряет взаимодействие, расспрашивая участников об использовании ими различных аспектов Spring Frameworks, таких как традиционные веб-приложения в сравнении с реактивными или те, которые используют современные функции, такие как виртуальные потоки, представленные в Java 21. Цель состоит не только в том, чтобы поделиться идеями, но и в том, чтобы вдохновить разработчиков на всех этапах — от начинающих до продвинутых — внедрять новые методы, повышающие производительность.

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

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

Достижение баланса: сопрограммы как оптимальное решение Сочетание Spring Framework с сопрограммами обеспечивает сбалансированный подход, сохраняя стиль последовательного программирования и эффективно используя асинхронные возможности. Этот метод поддерживает параллелизм без ущерба для управления ресурсами или устойчивости по сравнению с чисто реактивными платформами, такими как WebFlux. Однако для достижения наилучших результатов по-прежнему требуются неблокирующие библиотеки; в противном случае могут возникнуть проблемы, аналогичные тем, которые наблюдаются в традиционных установках.

Сопрограммы обладают уникальным преимуществом, сочетая преимущества упрощенных потоков с синхронным выполнением логики. Это позволяет разработчикам писать код, который выглядит последовательным, хотя и выполняется асинхронно, что повышает производительность и результативность. Однако сопрограммы создают некоторую помеху из-за использования ключевого слова "suspend", которое ограничивает вызов определенных методов из обычных функций без их блокировки. Несмотря на это ограничение, они обеспечивают отличные структуры параллелизма и легко интегрируются с такими платформами, как WebX или реактивное программирование.

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

Проект Loom, который разрабатывается уже более шести лет, направлен на усовершенствование платформы Java за счет внедрения виртуальных потоков. Эти потоки разработаны для обеспечения высокой производительности и простоты использования, аналогично сопрограммам. Начиная с версии JDK 21, виртуальные потоки стали окончательно доступны и могут использоваться в производственных средах. В дополнение к виртуальным потокам, Project Loom включает в себя структурированный параллелизм и ограниченные значения — концепции, которые соответствуют областям действия сопрограммы и контекстам соответственно. Этот многогранный подход обеспечивает комплексную основу для эффективного управления параллельным программированием.

Виртуальные угрозы концептуально схожи с сопрограммами, что позволяет выполнять большое количество одновременных операций. В то время как потоки ядра в Java ограничены и дороги, виртуальные угрозы могут выполняться с помощью облегченных потоков-носителей, представленных в GVM 21. Эти потоки-носители управляют выполнением множества виртуальных угроз, не будучи привязанными к ним напрямую. Хотя существует некоторая путаница в терминологии, когда все ссылки заменяются словом "угроза", в архитектуре сосуществуют как платформенные, так и виртуальные угрозы.

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

Сравнение производительности: сопрограммы по сравнению с традиционными потоками При сравнении сопрограмм и традиционной многопоточности при выполнении по 100 000 экземпляров каждой становится очевидным, что, хотя сопрограммы могут выполняться без проблем с памятью примерно за две секунды, создание слишком большого количества традиционных потоков приводит к ошибке нехватки памяти примерно через 8000 из-за нехватки памяти. В отличие от виртуальных потоков, выполняющих аналогичный код, это приводит к неблокирующему поведению; они приостанавливают, а не блокируют выполнение во время спящих операций, что позволяет завершить их примерно за две секунды, не истощая системные ресурсы.

Повышение производительности с помощью виртуальных угроз Виртуальные угрозы просты в использовании и могут повысить производительность за счет предотвращения блокировки потоков во время операций ввода-вывода. В реактивном программировании следует использовать неблокирующие библиотеки, чтобы освободить потоки платформы для новых задач и избежать неэффективного использования ресурсов. При использовании блокирующих библиотек или собственных вызовов необходим выделенный поток; однако virtual threats модифицировали устаревшие API, чтобы предотвратить блокировку потоков-носителей, но при этом обеспечить их безопасное приостановление и возобновление.

Возрождение старых технологий с помощью современного параллелизма Переход от традиционных синхронных блоков в таких фреймворках, как Spring Boot, был сложным из-за необходимости переписывания кодовой базы с учетом современных моделей параллелизма без привязки потоков-носителей. Несмотря на первоначальные рекомендации в последние годы отдавать предпочтение веб—клиентам, а не шаблонам rest, оба они одинаково хорошо работают при использовании с виртуальными потоками, демонстрируя неожиданное возрождение старых технологий наряду с новыми стеками.

Чтобы использовать виртуальные потоки в Spring Boot, убедитесь, что у вас установлен JDK 21 и Spring Boot версии 3.2 или выше. Включите виртуальные потоки, установив значение true для свойства "spring.threats.virtual.enabled" в файле свойств вашего приложения. После внесения этого изменения выполнение нагрузочного теста с одновременными пользователями демонстрирует значительное повышение производительности, поскольку запросы обрабатываются более эффективно с использованием виртуальных потоков.

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

Понимание эффективности потоков: Виртуальные угрозы в сравнении с угрозами платформы Сочетание Spring Web с виртуальными потоками позволяет использовать простые модели программирования, одновременно повышая эффективность использования ресурсов для операций, связанных с вводом-выводом. Однако возникают проблемы, связанные с параллелизмом, поскольку задачи, связанные с центральным процессором, не получают существенной выгоды от этой модели из-за ограничений в переключении между типами угроз после их запуска с помощью виртуальной угрозы. Понимание различия между работой, связанной с вводом—выводом, и работой, связанной с процессором, имеет решающее значение, поскольку это влияет на работу потоков в приложениях - виртуальные угрозы превосходно справляются с управлением многочисленными параллельными подключениями, но не справляются с большими вычислительными нагрузками, когда традиционные платформенные угрозы могут быть более эффективными.

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

Виртуальные потоки ненавязчивы и обеспечивают эффективное использование ресурсов, особенно для существующих приложений, таких как Spring MVC. Они улучшают использование аппаратного обеспечения, не требуя существенных изменений в кодовой базе, что упрощает управление потоковыми методами для каждого запроса. Однако гибкость ограничена, поскольку вернуться к традиционным потокам не так-то просто. Project Loom нацелен на достижение оптимальной производительности с помощью виртуальных потоков при одновременном использовании передовых концепций, таких как параллелизм и структурированный параллелизм.

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

Loom стремится внедрить структурированный параллелизм в Java, хотя он все еще находится на стадии разработки и пока не подходит для использования в производственной среде. Основное внимание уделяется двум ключевым функциям: структурированному параллелизму и ограниченным значениям. Пользователи могут поэкспериментировать с этими функциями, включив определенные флаги при запуске JVM, что дает представление о направлении работы Loom без полной реализации.

Структурированный параллелизм Kotlin позволяет запускать несколько асинхронных процессов в рамках одной области, гарантируя их завершение перед переходом к следующей задаче. Это контрастирует с подходом Java, который требует явной обработки задач и исключений с помощью таких конструкций, как futures, которые могут блокировать выполнение. В то время как Kotlin предлагает более элегантное решение с синтаксисом async/await, Java разработала свою будущую реализацию для поддержки неблокирующего поведения с использованием виртуальных потоков. Продолжающееся развитие обоих языков предполагает потенциальную оптимизацию и улучшения по мере развития их моделей параллелизма.

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

Исключение задач из процесса отмены имеет решающее значение для некоторых платформ, требующих очистки ресурсов. Хотя project Loom не поддерживает эту функцию, он использует прерывание потока как фундаментальный механизм. Это ограничение влияет на структуру процессов отмены, делая их менее гибкими по сравнению с другими системами, такими как Cines. Будущие предложения могут быть направлены на внедрение более сложных механизмов управления задачами и упорядочения отмен.

Распространение контекста является сложной задачей, особенно при использовании сопоставленного диагностического контекста (MDC) для ведения журнала, который использует локальное хранилище потоков. Такая зависимость создает неопределенность в отношении того, в каком потоке выполняется сопрограмма, что приводит к потенциальной потере состояния. Чтобы решить эту проблему, в Java были введены значения scope, которые позволяют эффективно распространять контекст из локального потока между сопрограммами. Однако интеграция этих новых решений в существующие платформы остается проблематичной из-за их зависимости от традиционных механизмов локального потока.

Реактивные потоки представляют собой проблему из-за отсутствия встроенной поддержки структурированного параллелизма. Разработчикам приходится полагаться на существующие реактивные платформы, такие как Flux для Spring Web, Flow для Quarkus и Vertex. Хотя при работе с виртуальными потоками это может вызывать разочарование, разработчики Kotlin извлекают выгоду из возможности легко преобразовать эти примитивы в потоки. Это преобразование облегчает интеграцию между традиционным реактивным программированием и современными моделями параллелизма.

Область действия Str имеет ограничения, особенно в локальных контекстах потоков, таких как безопасность транзакций. Хотя можно распространять локальное состояние потоков вручную, это создает проблемы. Существующие платформы потребуют значительных изменений для обеспечения совместимости. Примечательно, что транзакции Spring web не являются потокобезопасными в рамках одного контекста запроса; однако реактивные транзакции обеспечивают безопасность в нескольких областях. Если не учитывать эту несовместимость, она может привести к серьезным проблемам.

Вердикт по проекту Java Loom предполагает, что, хотя он предлагает значительные улучшения в области параллелизма, особенно выгодные для разработчиков Java за счет упрощения использования структурированных областей задач, существуют ограничения. Сложность существующих фреймворков, таких как Reactor, остается проблемой, поскольку они могут не полностью интегрироваться с возможностями Loom. Кроме того, считается, что модель параллелизма Loom уступает сопрограммам из-за ее зависимости от thread API и присущих ей ограничений. Есть опасения по поводу того, насколько хорошо этот новый подход будет сочетаться с текущими библиотеками и реактивными потоками на практике.

Избегайте блокировки вызовов в неблокирующих платформах Объединение виртуальных потоков с сопрограммами может повысить производительность, но неправильная интеграция приводит к проблемам. Использование Spring Web вместо Spring WebFlux для вызовов сопрограмм приводит к блокированию, что сводит на нет преимущества параллелизма. Соблазн использовать методы блокировки запуска в неблокирующей среде часто вводит разработчиков в заблуждение, вызывая последовательное выполнение, а не параллелизм.

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

Правильные стратегии интеграции сопрограмм Для эффективного использования сопрограмм в приложениях Spring Boot зависимости должны быть правильно настроены с самого начала с использованием функций приостановки для надлежащего управления контекстом в цепочках вызовов. Это обеспечивает плавное распространение состояния без потери важных контекстов транзакций или безопасности во время параллельных операций.

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

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