Given how virtual-thread creation and blocking work, when are virtual threads the wrong tool, and what design pitfalls remain?

## Recap of the mechanism (so the limits make sense) A **virtual thread** is a JVM-managed thread that runs on a small pool of **carrier** (platform/OS) threads. It is **cheap to create** and, on a **JDK blocking call** (I/O, `Thread.sleep`, locks, `BlockingQueue`), it **unmounts** from its carrier, freeing the carrier for other work. That single property — cheap creation + unmount-on-block — is what makes them scale, and every limitation below is a place where that property doesn't hold or where old habits fight it. ## 1. CPU-bound work: no benefit Unmounting only happens when a thread **blocks**. A thread doing pure computation never blocks, so it never frees its carrier; you're limited by the number of cores exactly as with platform threads. Throwing a million virtual threads at CPU-bound work just adds scheduling overhead. **Use a sized pool / parallel streams / fork-join for CPU-bound work; virtual threads for I/O-bound.** ## 2. Pinning: the carrier gets stuck **Pinning** = a virtual thread blocks but **stays mounted**, so its carrier can't run anything else. Classic causes: - Blocking **inside a `synchronized` block/method** (the monitor is bound to the carrier). - Executing **native (JNI)** frames while blocking. If many virtual threads pin simultaneously, you exhaust the (small) carrier pool and throughput collapses — the very scenario virtual threads were meant to avoid. **Mitigations:** prefer `ReentrantLock` over `synchronized` around blocking sections; keep native calls short; monitor for pinning (JFR `jdk.VirtualThreadPinned` events). (Later JDKs removed much `synchronized` pinning, but native pinning and the design lesson remain.) ## 3. Don't pool them **Thread pools** exist to amortize the high cost of creating platform threads. Virtual threads are cheap to create, so pooling them is an **anti-pattern**: it serializes work behind a fixed worker count and throws away the concurrency you wanted. Use `newVirtualThreadPerTaskExecutor()` (one per task) or just create them directly. ## 4. Thread-locals become expensive at scale A **`ThreadLocal`** holds a per-thread value. With a handful of pooled platform threads, using a thread-local as a cache (e.g. a `SimpleDateFormat`, a buffer) was a reasonable optimization. With **millions** of virtual threads, that becomes millions of copies — a memory blow-up. Also, inheritable thread-locals get copied on creation. **Mitigations:** audit thread-local usage, disable inheritance via the builder (`.inheritInheritableThreadLocals(false)`), and prefer **`ScopedValue`** (immutable, scoped, shareable context) for passing context. ## 5. Lost backpressure / fan-out overload A bounded pool used to be implicit **backpressure**: only N tasks ran at once, protecting downstreams. A per-task virtual-thread executor is effectively **unbounded** — it will happily start 100k concurrent calls and overwhelm a database, an API, or a thread-unsafe resource. **Mitigation:** cap concurrency explicitly with a `Semaphore` (acquire before the blocking call, release after) or a rate limiter. Virtual threads remove the *thread* limit but not the *resource* limit. ## 6. Downstream bottlenecks dominate If every task ultimately blocks on a **fixed-size shared resource** — a JDBC connection pool of size 10, say — then no matter how many virtual threads queue up, real throughput is capped at 10. Virtual threads make the *waiting* cheap but don't enlarge the scarce resource. Size the actual bottleneck. ## 7. Latency vs throughput Virtual threads improve **throughput** (how many concurrent blocked tasks you can sustain), not the **latency** of any single task. A request that waits 200 ms on I/O still waits 200 ms. Don't pitch them as making code faster. ## The principal-level mindset Virtual threads make **blocking cheap, not free**, and they shift the system's limit from *thread count* to *actual resources and contention*. The job is to (a) reserve them for I/O-bound concurrency, (b) eliminate pinning, (c) drop pooling/thread-local habits, and (d) reintroduce explicit backpressure and right-size the true bottlenecks.