Впроваджуємо віртуальні потоки Java (Project Loom) у продакшен

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Це четверта частина із циклу статтей про Project Loom, але й могла би бути самостійною, тож якщо ви пропустили минулі частини, то рекомендую їх переглянути: Частина 1 | Частина 2 | Частина 3

Ось і фінальна частина циклу статей про віртуальні потоки, що будуть впроваджені у релізі JDK 19 від 20 вересня 2022 року. Будь ласка, враховуйте, що віртуальні потоки та нові API типу StructuredTaskScope та Continuations є preview-функціоналом, тому для їх використання потрібні --enable-preview та модуль з інкубатора — jdk.incubator.concurrent. Основною метою усіх частин циклу є спроба привернути ще більше уваги у тієї аудиторії, яка за певних обставин використовує старі версії JDK або прагне розвивати функціонал своїх проєктів до якісно іншого рівня.

Фінальна части циклу є менш технічною, але вкрай показовою, бо дає відповідь на одвічне питання — а коли ж цей новий функціонал вийде «у продакшен». Тому я вирішив зробити підбірку проєктів, які вже зараз впроваджують надбання Project Loom.

Apache Tomcat

Tomcat надав експериментальну підтримку віртуальних потоків у рамках свого релізу 10.1.0-M16 ще в червні, але в ньому була виявлена помилка, яка порушувала підтримку HTTP/2 при відключеному асинхронному I/O. У ще не випущеному 10.1.0-M17 буде виправлено цю помилку. Більше деталей тут — tomcat.apache.org/...​t-10.1-doc/changelog.html

Jetty

Асинхронний HTTP сервер на базі Java Jetty об’єднав зміни для підтримки Project Loom на базі github.com/...​jetty.project/issues/8007. Оновлений функціонал стане частиною релізів версії 10.0.x, ймовірно, починаючи з 10.0.12

Helidon

Починаючи з версії 4.0, буде поставлятися збірка Project Nima (доступна тут), сервером, повністю написаним на основі віртуальних потоків, з такою ж продуктивністю, як у Netty. Отже, слідкуйте за оновленнями @helidon_project.

Quarkus

Надзвуковий, субатомний Java-сервер @QuarkusIO в травні об’єднав підтримку віртуальних потоків (github.com/...​rkusio/quarkus/pull/24942), яка вийшла у версії 2.10.0 в червні.

Vert.x

Один з популярних наборів інструментів Vert.x вже працює над впровадженням віртуальних потоків. Деталі тут vertx.io/...​irtual-threads-incubator

PiranhaCloud

Інструмент для створення cloud-ready контейнерів @piranha_cloud підтримує віртуальні потоки з липня: github.com/...​hacloud/piranha/pull/2635

Javalin

Легкий та орієнтований на простоту вебфреймворк @javalin_io використовує віртуальні потоки за замовчуванням на #Java19+, починаючи з версії 4.0.0.ALPHA2 (з травня): javalin.io/...​lin-4-development-updates

GraalVM

@graalvm кілька тижнів тому об’єднав підтримку віртуальних потоків в нативних образах. Збірка GraalVM на базі JDK 19 буде доступна вже після релізу JDK 19. Більше інформації тут

Oracle JDBC

Драйвер Oracle JDBC був доопрацьований для підтримки віртуальних потоків і використовує тільки java.util.concurrent блокування, починаючи з версії 21.1.

Проєкти, які почали роботу над впровадженням

Spring має випуск 6.0 (github.com/...​ng-framework/issues/23443), що означає для мене, що він також буде доступний в SpringBoot 3.0. Але вже зараз є вдалий експеримент — github.com/...​irtual-threads-experiment.

Micronaut планує впровадження віртуальних потоків у релізі 4.0.

OpenLiberty теж планує впровадження, але без чітких планів github.com/...​open-liberty/issues/21034.

Для IDE типу VSCode (github.com/...​de-java-debug/issues/1159), IntelliJ та Eclipse (github.com/...​lipse.jdt.debug/issues/38), віртуальні потоки стануть певною проблемою, лише враховуючи можливості масштабування кількості потоків.

Трохи висновків

Хоч Project Loom вже досить давно знаходиться у розробці і вже зазнав певних трансформацій (від fibers до virtual threads), до релізу ми дійшли лише зараз, щоб функціонал тих компонентів, що будуть доступні вже у JDK 19, був на вищому рівні. У найближчий реліз увійдуть два великих блоки:

  • VirtualThread, що докорінно змінює формат роботи з потоками та їх масштабуванням, при тому, не ламаючи функціоналу платформних (або системних потоків), а також, розширюючи функціонал Executors, ExecutorService, Thread та ThreadFactory.
  • StructuredTaskScope, як реалізація структурного паралелізму у Java, метою якого є повна або часткова заміна асинхронного програмування.
  • Continuations — об`єкт виконання якого можна «припаркувати» за певних умов й відновити з точки паркування (схожий концепт на генератори та корутини у Python). На цей час цей функціонал не є публічним, але планується стати таким з наступними preview-релізами.

Важливо знати, що увесь новий функціонал не одразу стає «стандартною» фічею, а проходить етапи Preview Release [1, 2 ,3], тому моє персональне прохання — пограйтеся з новим функціоналом, адже нам, розробникам JDK, вкрай необхідний зворотній звʼязок!

----

dev.java | inside.java | Java on YouTube | Java on Twitter | Me on Twitter

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Оце однозначно має стати «стандартною фічею», і скажу відверто, буде вже ніяково повертатися до старих звичок, коли попадеться легасі. А воно ж ще довго буде попадатися.

Від так, ключове питання — а чи варто рефакторити легасі на використання віртуальних потоків? Зазвичай відповідь «ні», але тут питання дещо інше: чи є невирішені проблеми легасі, які вирішаться рефакторингом, чи краще відкласти це питання на 2 роки та протестити на чужих помилках?

Від так, ключове питання — а чи варто рефакторити легасі на використання віртуальних потоків?

ні, бо віртуальні потоки сумісні із платформенними, єдине що треба змінити, це який саме використовується ExecutorService, ось тут (dou.ua/forums/topic/38676) я показую як саме створити ExecutorService щоб, виділялися віртуальні потоки під задачі замість платформенних.

Якщо ж у вашому легасі-коді ви явно викликали Thread::start, замість ExecutorService, то нажаль так, доведеться.

чи є невирішені проблеми легасі, які вирішаться рефакторингом, чи краще відкласти це питання на 2 роки та протестити на чужих помилках?

Наразі є лише одне питання — як жити із ThreadLocal. На заміну їм розробляються ExtentLocal як більш підходящя альтернатива для віртуальних потоків враховуючи їх потенційну масштабованість.

Підписатись на коментарі