Java 21 Virtual Threads — 83% faster, 75% fewer threads

Context

The report scheduler was the most thread-hungry service we ran. Peak concurrency hit at end-of-day settlement: hundreds of jobs, each blocking on database I/O and SFTP delivery. Under Java 11 platform threads, we kept hitting GC pressure spikes that bled into latency tail on otherwise-healthy services on the same node.

The upgrade had been sitting in the backlog for a quarter. I wrote the technical RFC, validated the path with a load-test harness, and got it through review.

Decisions

Tuning the platform-thread pool would have masked the symptom rather than fixing it, so the upgrade went straight to Java 21 and virtual threads. The workload was I/O-bound waiting on database calls and SFTP. Cooperative scheduling was what it actually needed.

The same change added an API delivery channel alongside the existing email and SFTP. Bundling it in kept the review surface small and gave Reporting consumers a non-batch path they had been asking for.

Cutover was a dual-run, not a big-bang. Both schedulers ran against the same job catalog for two weeks with the new one in shadow mode, and we diffed outputs daily before flipping traffic.

Results

• Peak thread usage down 75%.
• Report generation time down 83% (12 min → 2 min, end-of-day settlement window).
• GC pressure spikes eliminated; co-located services no longer affected.
• New API channel adopted by 3 internal consumers within the first month.

Stack notes

The least obvious cost was the JDBC driver. A few connection pools we used didn’t pin properly when the carrier thread was virtual, which would have made the upgrade worse, not better, under load. Catching that in the load-test harness before production was the real win. The version bump itself was a one-line change.