Was this article helpful?
to mark as helpful
Enjoyed this article?
Get more engineering insights delivered weekly.
Comments
to join the discussion
Note This series uses Java 21 as the baseline. Part 1 uses virtual threads only (JEP 444), so no preview flags are needed here. Later parts that use structured concurrency (
StructuredTaskScope, JEP 453) require--enable-preview. See Part 9 for Java 21 -> Java 25 migration guidance.
TL;DR
- Virtual threads make high-concurrency I/O workloads practical with much lower per-task overhead than platform threads
- They run on carrier threads (platform threads) via M:N scheduling
- You keep the familiar Java thread model and blocking style
- They are a strong fit for I/O-bound services, with caveats for CPU-bound work and downstream bottlenecks
The Problem: Traditional Threading Hits a Wall
Load tests of high-concurrency services often reveal the same ceiling: systems fall over at a few thousand concurrent users, even when business logic is simple.
The old pain point is straightforward: platform threads are expensive. Each one consumes 1-2MB of memory and uses real OS resources. In practice that puts a ceiling on concurrency long before business traffic does.
Consider this project example using a platform-thread pool for a blocking endpoint:
java
public class PlatformThreadPoolServer {
private static final int PORT = 8080;
private static final int THREAD_POOL_SIZE = 20;
private static final long BLOCKING_SIMULATION_TIME = 200;
public static void main(String[] args) throws IOException {
ExecutorService threadPoolExecutor = Executors.newFixedThreadPool(THREAD_POOL_SIZE);
HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
server.createContext("/api", exchange -> {
threadPoolExecutor.submit(() -> {
try {
Thread.sleep(BLOCKING_SIMULATION_TIME);
String response = "Platform Thread Ok\n";
exchange.sendResponseHeaders(200, response.length());
exchange.getResponseBody().write(response.getBytes());
exchange.close();
} catch (Exception e) {
e.printStackTrace();
}
});
});
server.setExecutor(null);
server.start();
}
}
Why this approach breaks down at scale:
- Pool Saturation: Each blocking call ties up a platform thread until completion
- Queueing Delays: Requests wait when the pool is full
- Scaling Cost: Bigger pools increase memory and scheduling overhead
- Latency Spikes: Tail latency grows quickly under burst traffic
Most of us worked around this with larger thread pools, callback chains, or reactive plumbing. It worked, but usually at the cost of readability and operability.
The Solution: What Virtual Threads Change
Virtual threads solve this with M:N scheduling, mapping many lightweight virtual threads onto a smaller set of carrier threads (platform threads).
In this project, the virtual-thread variant keeps the same blocking style:
java
public class VirtualThreadPoolServer {
private static final int PORT = 8080;
private static final long BLOCKING_SIMULATION_TIME = 200;
public static void main(String[] args) throws IOException {
ExecutorService loomExecutor = Executors.newVirtualThreadPerTaskExecutor();
HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
server.createContext("/api", exchange -> {
loomExecutor.submit(() -> {
try {
Thread.sleep(BLOCKING_SIMULATION_TIME);
String response = "Virtual Thread Ok\n";
exchange.sendResponseHeaders(200, response.length());
exchange.getResponseBody().write(response.getBytes());
exchange.close();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} catch (Exception e) {
e.printStackTrace();
}
});
});
server.setExecutor(null);
server.start();
}
}
What changed in this example:
- Executor type: per-task virtual threads instead of a fixed platform-thread pool
- Blocking code stays readable
- Higher concurrency headroom for I/O-heavy workloads
Deep Dive: How Virtual Threads Work
The Architecture
Understanding this model is key:
The M:N scheduling model maps many lightweight virtual threads onto a small pool of OS-managed carrier threads (one per CPU core by default). When a virtual thread blocks on I/O, it parks — releasing its carrier thread immediately so the carrier can run another virtual thread. This is the core mechanic that allows 100,000+ concurrent virtual threads on just a handful of platform threads.
Virtual Thread Creation Patterns
Thread creation patterns look similar, but runtime characteristics differ significantly:
java
public class LoomThreadTest {
public static void main(String[] args) throws InterruptedException {
int n = 10_000_00;
System.out.println("Running platform threads...");
long start = System.currentTimeMillis();
List<Thread> threads = new ArrayList<>();
// Platform thread loop will likely OOM; shown for contrast only.
for (int i = 0; i < n; i++) {
Thread t = new Thread(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException ignored) {}
});
threads.add(t);
t.start();
}
for (Thread t : threads) t.join();
long end = System.currentTimeMillis();
System.out.println("Platform threads took: " + (end - start) + " ms");
System.out.println("\nRunning virtual threads...");
start = System.currentTimeMillis();
threads.clear();
for (int i = 0; i < n; i++) {
Thread t = Thread.ofVirtual().unstarted(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException ignored) {}
});
threads.add(t);
t.start();
}
for (Thread t : threads) t.join();
end = System.currentTimeMillis();
System.out.println("Virtual threads took: " + (end - start) + " ms");
}
}
The Virtual Thread Lifecycle
The lifecycle behavior matters more than syntax:
- Creation: Virtual threads start with a small footprint (often far smaller than platform-thread stacks)
- Mounting: When scheduled, virtual thread mounts on a carrier thread
- Parking: When blocked (I/O, sleep), virtual thread parks and carrier thread is freed
- Unmounting: Carrier thread can now run other virtual threads
- Resumption: When I/O completes, virtual thread remounts on available carrier
The important bit is parking/unmounting: blocked virtual threads free carrier threads to run other work.
Illustrative Example: Large Virtual-Thread Count Test
java
private static final int VIRTUAL_THREAD_COUNT = 200_000;
private static void testVirtualThreads() throws InterruptedException {
System.out.println("Testing Virtual Threads...");
long start = System.currentTimeMillis();
List<Thread> threads = new ArrayList<>();
for (int i = 0; i < VIRTUAL_THREAD_COUNT; i++) {
Thread t = Thread.ofVirtual().unstarted(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException ignored) {}
});
t.start();
threads.add(t);
}
for (Thread t : threads) {
t.join();
}
long end = System.currentTimeMillis();
System.out.println("Virtual threads completed in: " + (end - start) + " ms");
System.out.println("Virtual threads created: " + threads.size());
}
How to read this test:
- It is illustrative, not a production sizing target
- Holding large numbers of
Threadreferences in aListadds heap overhead and skews memory results - Real limits usually come earlier: heap size, file/socket descriptors, DB pools, and downstream service capacity
- In production, prefer
executor.submit(...)without holdingThreadreferences
If you benchmark this pattern, treat it as an experiment. For realistic load testing, avoid keeping every Thread reference and validate end-to-end bottlenecks.
java
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (int i = 0; i < 200_000; i++) {
executor.submit(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
}
}
Performance Analysis
Memory Comparison
This is a simplified comparison to build intuition:
| Thread Type | Typical Footprint Pattern | At Very High Counts | Reality Check |
|---|---|---|---|
| Platform Thread | MB-scale stack per thread | Becomes impractical quickly | OS/thread limits and memory pressure hit early |
| Virtual Thread | Small initial footprint, grows with stack | Usually far lower memory pressure | Still bounded by heap and downstream resources |
Throughput Characteristics
text
- VirtualThreadFlood and LoomThreadTest in this project focus on blocking/sleep-style workloads.
- For CPU-bound work, virtual threads usually do not outperform platform threads.
Key point: virtual threads do not automatically speed up compute-heavy code. They improve scalability and utilization for blocking I/O workloads.
Caveats: I/O Scalability Still Has Limits
- Virtual threads improve request concurrency, but they do not increase downstream capacity by themselves
- Database pools, external API quotas, socket/file descriptor limits, and queue capacities still set hard ceilings
- Keep pinning under watch (
synchronizedhot paths, long native calls) because pinning can erase virtual-thread gains - Pinning improvements continue in later JDKs (e.g., JEP 491 in Java 24+)
- Validate with end-to-end load tests, not thread-count tests alone
Key Takeaways
When to Use Virtual Threads
Best fit for:
- Web servers handling many concurrent requests
- I/O-bound operations (database calls, file operations, network calls)
- Task queues and background processing
- Microservices with high concurrency requirements
Use caution / alternatives for:
- CPU-intensive computations (number crunching, algorithms)
- Applications with few concurrent operations (overkill)
- Legacy code that relies on ThreadLocal heavily (requires careful migration)
Migration Strategy
A practical migration sequence:
- Start Simple: Replace
Executors.newFixedThreadPool()withExecutors.newVirtualThreadPerTaskExecutor() - Test Thoroughly: Virtual threads have different characteristics - monitor memory and CPU
- Monitor Performance: Use JFR to observe virtual thread behavior and carrier pinning
- Gradual Rollout: Start with non-critical services, then expand based on results
Best Practices
Operational guidelines:
- Avoid Thread Pools: Virtual threads are cheap to create - don't pool them!
- Use Blocking I/O intentionally: Prefer clear blocking flows where virtual threads remove thread-hoarding costs
- Monitor Pinning: Watch for cases where virtual threads pin to carriers (synchronized blocks, native calls)
- Keep it simple: Clear synchronous-style flows are easier to debug and operate
What's Next?
In Part 2, we'll build a high-performance web service using virtual threads and walk through C10K-style behavior with practical load testing.
We'll explore:
- Building HTTP servers with virtual threads under high concurrency
- Handling database connections efficiently without excessive pool/thread tuning
- Comparing performance with traditional thread pools in real scenarios
- Production patterns and monitoring strategies that actually work
Resources
- Complete Code: project-loom-learning repository - All examples (feature/java-21) are runnable
- Official Documentation: JEP 444: Virtual Threads
- Try It Yourself: Clone the repo and run the examples with Java 21+
Part 1 complete. We covered the bottleneck and the execution model; next we build a real service with it.
Next up: Part 2: Building High-Performance Web Services with Virtual Threads →