Java’s approach to concurrency has come a long way. With the arrival of virtual threads in Java 19, there’s renewed interest in how they compare to the older green threads — and why they solve many of the challenges that once limited Java’s scalability. Let’s explore how these two models differ, what problems they address, and how virtual threads are designed for today’s workloads.
Overview of Threading Models
| Thread Type | How It Works | Mapping |
|---|---|---|
| Platform Threads | Native OS threads managed by the JVM. Heavyweight and resource-intensive. | 1:1 |
| Green Threads | JVM-managed threads running on a single OS thread. Lightweight, but limited. | M:1 |
| Virtual Threads | JVM-managed threads that scale across multiple OS threads. Lightweight and flexible. | M:N |
What Were Green Threads?
Green threads were the original threading model used in early versions of Java. These threads were scheduled entirely by the JVM, not the operating system.
Drawbacks:
- No parallelism: All green threads ran on a single OS thread.
- Blocking issues: If one thread blocked (e.g., on I/O), all were affected.
- Outdated by OS improvements: Native thread management eventually became more efficient.
What Are Virtual Threads?
Virtual threads, introduced as a preview feature in Java 19 under Project Loom, are managed by the JVM but are designed to scale far beyond the limits of platform threads.
Key Advantages:
- True parallelism: They run across multiple OS threads.
- Non-blocking by design: Compatible with asynchronous I/O.
- Lightweight: Thousands (or even millions) can be created with minimal memory use.
- Easy integration: Can be created using familiar APIs like
RunnableandExecutorService.
How Virtual Threads Address the Limitations of Green Threads
| Feature | Green Threads (Old) | Virtual Threads (New) |
|---|---|---|
| OS Thread Use | Single thread (M:1) | Shared pool (M:N) |
| Parallel Execution | No | Yes |
| Blocking Behavior | Affects all threads | Doesn’t block OS threads |
| Scalability | Poor | Excellent |
Virtual threads are efficient because they pause when blocked (like during I/O), freeing the underlying OS thread for others to use — something green threads could never do.
Where Virtual Threads Work Best
- High-concurrency workloads: Web services, APIs, event-driven systems.
- I/O-heavy tasks: Database queries, network communication, file operations.
- Simplifying concurrency: Reduces the need for complicated thread pool management.
Frequently Asked Questions
Can they replace all threads?
Not quite. For CPU-intensive tasks, platform threads are still more appropriate due to their close tie to physical cores.
Do I need to rewrite my code?
No. Virtual threads work with existing Java concurrency APIs and are compatible with most existing code.
How do they compare to similar features in other languages?
They serve a similar purpose as lightweight concurrency tools like coroutines or goroutines but are built directly into the JVM without new language constructs.
Tips for Using Virtual Threads Effectively
- Avoid thread-local variables: These don’t play well with a large number of lightweight threads.
- Use structured concurrency: Helps manage thread lifecycles and dependencies cleanly.
- Monitor usage: Tools like JDK Flight Recorder can help you understand how threads behave at scale.
In Summary
Green threads were an early attempt to make threading more lightweight in Java, but their architecture was limited by their single-threaded nature. Virtual threads take a modern, scalable approach — allowing huge numbers of lightweight threads that are well-suited to today’s highly concurrent applications. They make it easier to write clean, readable, and scalable code without the complexity of traditional thread management.
Let me know if you’d like a visual diagram or side-by-side code example to go with this!
