Concurrency Crossroads: Choosing between Reactive Programming & Virtual Threads
summary
If code is simple CRUD or you want readable imperative code, keep blocking or use virtual threads with Quarkus and structured concurrency to get thread-per-request scale without rewriting. If you need strict backpressure, high fan‑out gateways or streaming, choose reactive (Mutiny Uni/Multi) with non‑blocking JDBC/Hibernate Reactive. Watch for surprises: synchronized pinning affected Loom until JDK 24, parallel transactions break DB sessions, and benchmarks show Spring gains more moving to Loom while Quarkus is already fast. Always test JFR events and CI pinning checks.
AI-written summary · about
chapters (10)
- 0:00Concurrency paradigms intro
- 1:02Threading models history
- 28:24Blocking IO limits
- 33:58Reactive programming basics
- 59:13Virtual threads intro
- 1:00:15How virtual threads work
- 1:18:47Using virtual threads
- 1:27:45Kotlin coroutines preview
- 1:37:45Ecosystem choices
- 1:48:21Performance comparison
related talks
51mQuarkus 3: The Road to Loom for Cheaper, Faster, and Easier Concurrent Applications
57mJDK 19 Virtual Threads: Skip Reactive, Boost Throughput
50mQuarkus 3: The Road to Loom for Cheaper, Faster, and Easier Concurrent Applications
47mReactive Programming - Royal Road or Wrong Turn?
51mQuarkus 3: Elevating Java Microservices with Project Loom and Beyond
38mReactive ❤️ Loom: A Forbidden Love Story
41mServices Reloaded Increased Throughput with Project Loom Virtual Threads
28mReactive Quarkus