Document virtual threads limitations

[PRIESt512]

Good afternoon.
I'd like to discuss the potential issue of enabling virtual threads at the platform level. I would update spring's documentation to use virtual threads. I would highlight this feature in red and warn other developers about possible problems. Virtual threads can be a very big problem if used incorrectly.
spring.threads.virtual.enabled: true - creates a strong temptation to install immediately and everywhere.
This property makes us think that the entire spring will work correctly with virtual threads. But this is definitely not the case.

Let's say I want to use spring-boot-starter-mail... I start sending a message in a virtual thread.
So what do I see? If I check the application with Flight Recorder I see a lot of jdk.VirtualThreadPinned events. If you look at the source code, this is an anti-pattern for virtual threads. There is synchronized inside and data is sent via the socket inside.
I sent messages 3 times and received 59 VirtualThreadPinned. Subject to triggering 20 ms, pinned time was from 100 to 900 ms...

Due to such limitations of virtual threads, you need to be extremely careful when using. Otherwise it can be fatal for the application.

Quote from Quarkus:

Monopolization cases
When running long computations, we do not allow the JVM to unmount and switch to another virtual thread until the virtual thread terminates. Indeed, the current scheduler does not support preempting tasks.

This monopolization can lead to the creation of new carrier threads to execute other virtual threads. Creating carrier threads results in creating platform threads. So, there is a memory cost associated with this creation.

Suppose you run in a constrained environment, such as containers. In that case, monopolization can quickly become a concern, as the high memory usage can lead to out-of-memory issues and container termination. The memory usage may be higher than with regular worker threads because of the inherent cost of the scheduling and virtual threads.

Pinning cases
The promise of "cheap blocking" might not always hold: a virtual thread might pin its carrier on certain occasions. The platform thread is blocked in this situation, precisely as it would have been in a typical blocking scenario.

According to JEP 425 this can happen in two situations:

when a virtual thread performs a blocking operation inside a synchronized block or method

when it executes a blocking operation inside a native method or a foreign function

See more details here

Before introducing virtual threads, you need to check the entire application in detail. The current state of java projects does not allow them to be used thoughtlessly. Not even all JDK classes can handle virtual threads - look at the class jdk.internal.misc.Blocker.
I see a lot of advertisements for virtual threads... Some may think that this is the solution to their problems. But virtual threads can be a problem. We need to talk about possible problems at every step.

Spring lacks the ability to fine-tune launch control in virtual threads. For example, you can enter an annotation like Quarkus - @RunOnVirtualThread. And it is also possible to add an annotation by analogy @ThreadSafe, @NotThreadSafe - @VirtualThreadSafe, @NotVirtualThreadSafe. In terms of severity I would equate it to thread safety.

The current java world is not fully prepared for virtual threads. They can create many more problems. But excessive advertising only makes the situation worse.

It is necessary to update the documentation and warn users very strongly about the risks that they can create for themselves and their systems.

P.S. I can pay a lot of attention to this. I can pay a lot of attention to this, but I'm worried about this new and dangerous opportunity. It should be used very carefully

[philwebb]

Spring lacks the ability to fine-tune launch control in virtual threads

Please track spring-projects/spring-framework#31212 for that enhancement.

[philwebb]

I feel like we have to be quite careful with the Spring Boot documentation so that it doesn't sprawl and attempt to cover every possible situation that can occur. This is especially true for new JDK features where the landscape is still shifting as folks adapt to the feature.

Whilst I'm not against adding some general warning, I think "highlight this feature in red and warn other developers about possible problems" is probably going a bit far. I think the ideal situation would be for us to link to something like https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html and leave others to document the limitations.

[PRIESt512]

I agree with your opinion.
I see the features of the documentation and how it saves time. Therefore, it is good to have a warning in the documentation about restrictions on the use of virtual threads. And developers must understand what they are doing.