Java Virtual Threads — Benchmark Results

Spring Boot 4 · Project Loom · 250 concurrent VUs · I/O-bound + CPU work (SHA-256, 4KB blobs, 80ms blocking)
2 pod profiles · 3 series each · bars = avg · dots = individual runs

500m · Platform (50-thread Tomcat pool)
500m · Virtual Threads
1CPU · Platform (100-thread Tomcat pool)
1CPU · Virtual Threads
Throughput & Latency
Throughput
Requests / second higher is better ↑ Virtual wins
/api/process — Average Latency
milliseconds lower is better ↓ Virtual wins
/api/process — p99 Latency
milliseconds lower is better ↓ Virtual wins
/api/status — Average Latency
milliseconds lower is better ↓ Virtual wins
/api/status — p99 Latency
milliseconds lower is better ↓ Virtual wins
Error Rate
percent lower is better ↓ Virtual wins
Resource Usage — Tradeoffs
Peak OS Threads
count lower = less OS overhead ↓ Virtual wins
Peak Heap Used
MB ↑ higher under virtual (more concurrency) Platform lower
Peak RSS Memory
MB (resident set) ↑ virtual uses more RAM Platform lower
CPU — Peak %
percent ↑ virtual uses more CPU (doing more work) Virtual: efficient
CPU — Average %
percent over test duration
GC Pressure
GC Events (total during test)
count ↑ more GC under virtual (more allocation) Platform lower
GC Pause Total
milliseconds cumulative stop-the-world time
Full Comparison — Averaged across 3 series
All metrics · green = better · red = worse · relative to platform threads baseline
ProfileMode Throughput (req/s)ProcAvg (ms)Proc p99 (ms) StatAvg (ms)Stat p99 (ms)Errors (%) OS ThreadsHeap (MB)RSS (MB) CPU avg (%)GC eventsGC pause (ms)
Raw Data — Individual Series
Per-run values
ProfileMode S1 req/sS2 req/sS3 req/s S1 PAvgS2 PAvgS3 PAvg S1 p99S2 p99S3 p99 S1 ThrS2 ThrS3 Thr S1 HeapS2 HeapS3 Heap S1 GCS2 GCS3 GC