Services Reloaded Increased Throughput with Project Loom Virtual Threads
summary
Claim: Project Loom virtual threads let synchronous thread-per-request code scale like reactive systems without rewriting APIs, using the JVM to schedule M:N threads. Demonstrations use JDK 19, configure Tomcat 10.1.1 or Jetty to use a virtual-thread executor, and frameworks like Quarkus nearly matches reactive throughput while Netty stays reactive-first. Caveats: JDBC and native/foreign libs can pin carrier threads—Oracle’s JDBC is updated—so third‑party blocking calls determine real scalability.
AI-written summary · about
chapters (6)
- 0:00Introduction and speaker intro
- 3:37Java thread history and evolution
- 10:28Reactive programming overview
- 21:20Project Loom virtual threads explained
- 31:39Using virtual threads in applications
- 39:06Q&A and future of Project Loom
related talks
57mJDK 19 Virtual Threads: Skip Reactive, Boost Throughput
36mPreparing web applications for Loom
38mReactive ❤️ Loom: A Forbidden Love Story
38mJava Project Loom: Why Should I Care?
31mJava Virtual Threads
39mProject Loom: Modern Scalable Concurrency for the Java Platform
35mUntangled: Sneak peek at Project Loom
48mAre Virtual Threads Going to Make Reactive Programming Irrelevant?
