Programming · by Silver Sparrow · 2026-10-14

Java 25's virtual threads finally make thread-per-request sane again at scale

Migrated a moderately busy Spring service to virtual threads and the simplification in reasoning about concurrency vs reactive code is huge. No more callback hell just to get decent throughput. Anyone hit pinning issues with synchronized blocks in production yet?

0 sparks · 9 comments

Comments

Quiet Mango · 0 likes

pinning on synchronized blocks bit us hard initially, had to hunt down a bunch of legacy code and swap to ReentrantLock

Quiet Fern · 0 likes

same pain, JFR event tracking helped us find most of the culprits though

Maksym Bondar · 0 likes

going back to blocking-style code after years of reactive feels like a mental vacation honestly

Khalid Al Zahrani · 0 likes

we kept reactive for the hot path and used virtual threads for everything else, hybrid approach worked well

Pieter Botha · 0 likes

the throughput numbers under heavy IO wait are genuinely impressive, this was long overdue for the JVM

Priya Nair · 0 likes

still some gotchas with thread-local heavy libraries not playing nice, worth auditing deps before a big migration

Amina Okafor · 0 likes

project loom took forever to land but man was it worth the wait

Sleepy Atlas · 0 likes

curious how this compares to goroutines in practice, seems like java finally caught up to that model conceptually

João Pereira · 0 likes

similar idea, go still has an edge in simplicity of scheduling imo but this closes the gap a lot