Are Virtual Threads Going to Make Reactive Programming Irrelevant?
summary
Claim: Java virtual threads (Loom) let you write simple blocking code instead of complex reactive pipelines while matching reactive throughput. Evidence: virtual threads shipped as a final feature in JDK 21, are as cheap as creating an object (not a millisecond or megabytes), and scale toward millions instead of the ~5,000 platform thread limit. Built features: Structured Concurrency (preview in JDK 24/25) auto-closes stray tasks and Scoped Values replace ThreadLocal for safe context propagation. Result: simplifies debugging, avoids lost threads, and preserves performance.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:37Project Loom and virtual threads
- 8:50Why reactive programming emerged
- 11:20Problems with threads
- 17:21Reactive programming benefits and drawbacks
- 25:56Debugging reactive code
- 30:50Virtual threads solve concurrency
- 34:05How virtual threads work
- 37:17Code with virtual threads
- 40:11Structured concurrency
- 42:18Virtual threads vs reactive
- 44:05Scope values replace thread locals
- 47:17Future of Loom
related talks
53mVirtual Threads: Ushering in a New Era of Concurrency
01h 00mLoom Virtual Threads in the JDK 20
47mConcurrent and Asynchronous Programming: Loom in Java 20 and 21
57mJDK 19 Virtual Threads: Skip Reactive, Boost Throughput
47mThe Challenges of Introducing Virtual Threads to the Java Platform - Project Loom
52mJava Virtual Threads
02h 43mVirtual Threads, Structured Concurrency and Scoped Values in Java 25 and Beyond
49mEven threads are now virtual:past, present, future of concurrency in Java.