We moved three services onto virtual threads last winter. Throughput barely moved on two of them, which surprised the team until we looked at where time was actually going.

The win is not speed

A virtual thread costs a few hundred bytes instead of a megabyte of stack. That does not make any single request faster. What it changes is that blocking stops being the thing you design around, and the reactive machinery you adopted to avoid it stops paying for itself.

If the only reason a service is reactive is that platform threads were expensive, virtual threads have removed the reason.

What actually bit us

• synchronized pins the carrier thread. We found two hot paths doing exactly that under a library we did not own.
• Pooling virtual threads is an anti-pattern. Create one per task and let them be cheap.
• ThreadLocal still works but scoped values fit the model better, especially for request context.

The migration was mostly deletion: swap the executor, hunt for pinning, and remove the operators that existed only to avoid blocking.