JDK 19 Virtual Threads: Skip Reactive, Boost Throughput
summary
Project Loom’s virtual threads claim: get reactive-level throughput while keeping thread‑per‑request code. It uses JDK 19/21 features, the new virtual-thread-per-task executor, and framework integrations (Tomcat/Jetty configs, Quarkus/Micronaut/Spring Boot options). Quarkus benchmarks show throughput nearly matching reactive stacks; Netty often doesn’t benefit. Known pitfalls: trace-pin-threads reveals pinning from synchronized/native calls, long‑running tasks and thread‑local caching break assumptions. Oracle’s Hodon team rewrites a server to use virtual threads, removes lots of code, and reports success.
AI-written summary · about
chapters (13)
- 0:00Introduction to virtual threads
- 2:56Historical context of Java threads
- 7:34Evolution of server-based applications
- 11:31Reactive Manifesto and APIs
- 18:49Challenges with reactive programming
- 21:33Project Loom and virtual threads
- 26:57How virtual threads work
- 31:51Creating and using virtual threads
- 34:38Web server support for virtual threads
- 36:25Microservice frameworks and virtual threads
- 39:14Spring Boot and virtual threads
- 41:40Third-party library compatibility
- 43:04Potential drawbacks and solutions
related talks
41mServices Reloaded Increased Throughput with Project Loom Virtual Threads
48mAre Virtual Threads Going to Make Reactive Programming Irrelevant?
38mReactive ❤️ Loom: A Forbidden Love Story
46mJava 21: The Revolution of Virtual Threads - A Deep Dive
53mVirtual Threads: Ushering in a New Era of Concurrency
01h 00mLoom Virtual Threads in the JDK 20
46mJava 21: The revolution of virtual threads - A Deep dive
51mJava 21: The revolution of virtual threads