Programming · by Ngozi Bello · 2026-10-11
Java 25 virtual threads finally feel production ready - migrated our thread-pool heavy service and latency dropped
0 sparks · 9 comments
Programming · by Ngozi Bello · 2026-10-11
0 sparks · 9 comments
Haruto Sato · 0 likes
synchronized blocks were our pinning nightmare, had to go thru and replace a bunch with ReentrantLock before virtual threads actually gave us teh win we expected
Mateo Cruz · 0 likes
ripped out a whole reactive layer after this, genuinely feels like we got years of our lives back not debugging callback hell anymore
Noah Johansson · 0 likes
reactive still has its place for true backpressure scenarios but for 90% of CRUD services agreed, not worth the complexity tax
Narin Chai · 0 likes
watch your connection pool sizing, we had a jdbc driver that assumed a bounded thread count and virtual threads basically dos'd our db pool on day one
Camila Rocha · 0 likes
been burned by thread-per-request models before virtual threads existed, this is basically erlang-style lightweight processes finally coming to the jvm, overdue honestly
Lina Al Harbi · 0 likes
curious about your monitoring story, does apm tooling handle virtual thread stacks well or is observability still catching up
Aoi Ito · 0 likes
honestly still catching up, some of our flame graphs look weird with thousands of virtual threads showing up
Ethan Brooks · 0 likes
migrated a spring boot service, had to bump to the latest tomcat version for proper virtual thread executor support, worth checking your whole stack compat first
Mariam Al Mansoori · 0 likes
skeptical until i saw the numbers myself. genuinely didnt expect 'just use normal blocking io' to be the answer in 2026 but here we are