Soon virtual threads in Java?

Filed this week, Oracle’s JDK Improvement Proposal (JEP) provides for the integration of virtual threads (execution unit) in the standard edition of Java (Java SE). They would dramatically reduce the effort required to write, maintain, and observe high-performance concurrent applications.

Moreover, they would complement those of Java with a lightweight implementation of user-mode threads. This implementation would make more efficient use of the available hardware, which would significantly reduce costs. According to the proposal, threads are useful for representing a concurrent unit of application, such as a transaction. The current implementation of Thread in Java consumes one OS thread for every Java thread, and OS threads are rare and expensive.

A high level of competition

A modern server can handle orders of magnitude larger concurrent transactions than OS threads. To use hardware efficiently, developers of broadband services needed to share threads between transactions. To achieve this, they used thread pools that lent threads to one transaction after another to save the cost of creating threads for each one. But, as that was no longer enough, the latter started returning threads to the pool even in the middle of a transaction, when they were waiting for I/O. This style of asynchronous programming requires a separate and incompatible set of APIs that makes troubleshooting, debugging, observing, and profiling very difficult.

Virtual threads are user-mode implementations of java.lang.Thread that do not block operating system threads, and facilitate near-optimal use of hardware. Virtual threads bring a high level of concurrency, as well as high throughput, while the program remains in harmony with the thread-based design of the Java platform and tools. Virtual threads are to platform threads what virtual memory is to physical RAM: a mechanism that provides an abundant “virtual” resource through automatic matching with the underlying physical resource.

A quick learning curve, but a change of practices to adopt

According to the proposal, it is not necessary to learn a new programming model to use virtual threads. Developers who use Java to write concurrent applications are already familiar with the pattern. However, developers will have to forget old practices implemented out of necessity due to the high cost of threads, especially the use of thread pools which are only useful when the resource they are pooling is scarce or expensive to to create.

Virtual threads are instances of java.lang.Thread implemented by the JDK in such a way as to make several active instances coexist in the same process. Virtual threads have the same semantics as platform threads, except that they belong to a single ThreadGroup and cannot be enumerated. The proposal, authored by Ron Pressler and Alan Bateman, both consulting members of Oracle’s technical team, does not specify which version of Java SE might include virtual threads. The current version of the JDK, shipping in September, is JDK 17.