Why Wouldn’t You Use Virtual Threads in Your Java Application?

If you're running on environments like AWS Lambda where the application lifecycle is very short, virtual threads may add unnecessary overhead. Since the app runs in milliseconds and uses just one thread, sticking with simpler options might yield better results without complicating things further.

Virtual threads are primarily designed for I/O operations rather than CPU-intensive tasks. For CPU-heavy work, using a dedicated thread pool is usually more efficient. Virtual threads rely on cooperative multitasking, which might lead to issues if threads don’t yield, potentially starving other threads of execution.

There are a few reasons why virtual threads might not be suitable for every application. For instance, if your app heavily relies on non-JVM code that could pin carrier threads, using a reactive or callback model might be more effective. Additionally, if you're working with frameworks not designed for virtual threads or need to support older JDK versions, that could be a problem. Overall, if you’re targeting JDK 21 or newer, using virtual threads generally seems advantageous without major drawbacks.

If you have CPU-bound tasks, the management overhead of virtual threads might be noticeable compared to traditional platform threads. They're primarily intended for I/O-heavy operations, so cramming a bunch of virtual threads onto a CPU core will likely not speed things up if you're already maxing out CPU usage.

It's important to measure performance when switching to virtual threads. In my experience, moving from Project Reactor to virtual threads decreased throughput by about 25%. Performance can vary based on your specific scenario, so thorough benchmarking is key before making such a change.