But rather to introduce this powerful paradigm that will greatly (in Oracle’s words “dramatically”) reduce the effort of creating very high scale concurrent workflows in Java. “Before Loom, we had two options, neither of which was really good,” said Aurelio Garcia-Ribeyro, senior director of project management at Oracle, in a presentation at the Oracle DevLive conference this week. You should use virtual threads if you have many tasks to be processed concurrently, which primarily contain blocking operations. On my 64 GB machine, 20,000,000 virtual threads could be started without any problems – and with a little patience, even 30,000,000. From then on, the garbage collector tried to perform full GCs non-stop – because the stack of virtual threads is “parked” on the heap, in so-called StackChunk objects, as soon as a virtual thread blocks. With the class HowManyVirtualThreadsDoingSomething you can test how many virtual threads you can run on your system.

• Previews are for features set to become part of the standard Java SE language, while incubation refers to separate modules such as APIs.
• In some cases, you must also ensure thread synchronization when executing a parallel task distributed over multiple threads.
• See the Java 21 documentation to learn more about structured concurrency in practice.
• On my 64 GB machine, 20,000,000 virtual threads could be started without any problems – and with a little patience, even 30,000,000.
• For long running requests when you are storing heavy / expensive data in ThreadLocal storage you’ll might want to release the data as soon as it’s not needed any more.

When you want to make an HTTP call or rather send any sort of data to another server, you (or rather the library maintainer in a layer far, far away) will open up a Socket. If I want to demonstrate the performance advantage of Virtual Threads over Platform Threads, I need to find a better use case. Parallel Streams work exceptionally well in this case, and it’s hard (impossible?) to do better. My expectation I could speed things up with Virtual Threads was a misunderstanding of how Virtual Threads are optimized.

Will your application benefit from Virtual Threads?

A preview of virtual threads, which are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput, concurrent applications. Goals include enabling server applications written in the simple thread-per-request style to scale with near-optimal hardware utilization (…) enable troubleshooting, debugging, and profiling of virtual threads with existing JDK tools. In the simplest terms a virtual thread is not directly tied to a particular OS thread while a platform thread is a thin wrapper around an OS thread. When these features are production ready, it should not affect regular Java developers much, as these developers may be using libraries for concurrency use cases. But it can be a big deal in those rare scenarios where you are doing a lot of multi-threading without using libraries. Virtual threads could be a no-brainer replacement for all use cases where you use thread pools today.

As the test results show, the test operation took much longer for traditional threads to execute compared to virtual threads. Well, as in any other benchmark it’s impossible to tell without having something to baseline of. So lets do the same processing using platform threads and see the comparison.

Virtual threads

A caveat to this is that applications often need to make multiple calls to different external services. With the gradual introduction of Project Loom, though, the availability of a new multithreading mechanism that is more performant than the traditional threads raises the question of whether one should replace coroutine-dependent code with code that leverages virtual threads. Much digital ink has already been spilled on this subject, and the consensus appears to be “probably not”. Why not “simply” use reactive programming for high throughput java applications? Well, per Java’s core team, reactive paradigm is not in harmony with the rest of the Java Platform and it’s not a natural way to write programs in Java.

Today with Java 19 getting closer to release, the project has delivered the two features discussed above. And yes, it’s this type of I/O work where Project Loom will potentially shine. In the case of IO-work (REST calls, database calls, queue, stream calls etc.) this will absolutely yield benefits, and at the same time illustrates why they won’t help at all with CPU-intensive work (or make matters worse). So, don’t get your hopes high, thinking about mining Bitcoins in hundred-thousand virtual threads. Prevalent issue with the current thread implementation is that it can limit the applications bandwidth to well below what the modern hardware can handle. Meaning in todays Java applications, especially web based software, what can cap your throughput is not CPU, memory or network but the amount of OS threads available to you, since Java threads directly wrap around operating system threads.

All together now: Spring Boot 3.2, GraalVM native images, Java 21, and virtual threads with Project Loom,

Note that for running this code enabling preview features is not enough since this feature is an incubator feature, hence the need to enable both either via VM flags or GUI option in your IDE. Your might have noticed already the first potential pitfall of the Thread Local design which is immutability or rather the lack of. In vast majority of use cases you will set the data once and only read that data throughout the request context, but that cannot be enforced easily, meaning data.set(“data”) can be called anytime, anyplace and any number of times.

As soon as the virtual thread encounters a blocking operation, the virtual thread is removed (“unmounted”) from the carrier thread, and the carrier thread can execute another virtual thread (a new one or a previously blocked one). At high levels of concurrency when there were more concurrent tasks than processor cores available, the virtual thread executor again showed increased performance. Why go to this trouble, instead http://protyazhno.ru/anpagelin90-1.html of just adopting something like ReactiveX at the language level? The answer is both to make it easier for developers to understand, and to make it easier to move the universe of existing code. For example, data store drivers can be more easily transitioned to the new model. On my machine, the process hung after 14_625_956 virtual threads but didn’t crash, and as memory became available, it kept going slowly.

Виртуальные потоки Project Loom

Asynchronous concurrency means you must adapt to a more complex programming style and handle data races carefully. The structured concurrency API is also designed to preserve order in multi-threaded environments by treating multiple tasks running in individual threads as a single logical unit of work. Without it, multi-threaded applications are more error-prone when subtasks are shut down or canceled in the wrong order, and harder to understand, he said. Virtual threads represent a lighter-weight approach to multi-threaded applications than the traditional Java model, which uses one thread of execution per application request.