I’ve been following the development progress of the
JDK concurrent library for a long time, but I was busy some time ago and rarely checked the official
The Java concurrent project Loom (because the project is still in the development stage, OpenJDK gives only a small amount of
Loom project-related information in the official website https://openjdk.java.net/projects/loom) has been established before
2018, and has been released based on
JDK17 compilation and JDK18 compilation, etc. Early versions, I only found the
JDK18 compiled version when I downloaded the early versions of Loom:
The download portal is at: https://jdk.java.net/loom
Due to the high version of this JDK, you can currently use the mainstream IDE to import Loom-JDK-18+9 for code highlighting and syntax reminder, temporarily can not find a way to compile, temporarily use the JDK execution directory of the javac command script to compile, using the java command script to run.
Brief introduction of Loom project
Loom - Fibers, Continuations and Tail-Calls for the JVM
The title of the Loom project already highlights the three main new features introduced.
Fibers: A few years ago I read the test code of the Loom project that was using the Fiber API (now this API has been removed), meaning lightweight threads, i.e., concurrent threads, also known as lightweight user threads, amazingly in the current JDK is actually called Virtual Thread (virtual threads)
Continuations: straight implementation is a bit like a closed package, reference to a lot of information, have not yet understood its exact meaning, feel that it can be “rough” interpreted as “what the program will execute next” or “the next block of code to be executed”
Tail-Calls: VM-level support for tail-calls
Three new features do not expand in detail, only the EA version, there is still the possibility of modification, so there is no need to expand in detail.
Virtual Thread use
The use of concurrency in the current version of the Loom project does not introduce a new public
VirtualThread class, although
VirtualThread does exist, this class uses the default modifier, is hidden in the java.lang package, and VirtualThread is a subclass of Thread. The API for creating a concurrent thread is located in the Thread class at
Use this API to create coroutines as follows.
From the current source code it is known that
VirtualThreadwill get the parent thread’s scheduler through Thread.currentThread(). If it runs in the main method, then the parent thread of the concurrent thread instance in the above code is the main thread
- The default scheduler is a system-created instance of
VirtualThread.DEFAULT_SCHEDULER), and the input
Runnableinstance is wrapped as a
RunContinuation, which is eventually executed by the scheduler
- For timed unpark (blocking, waiting to wake up), use the system-created ScheduledExecutorService instance to wake up
- This static factory method runs immediately after the coroutine is created and returns the coroutine instance
If you follow the
Thread.startVirtualThread() method above to create a coroutine, you obviously can’t define properties such as the name of the coroutine. the Loom project introduces a builder pattern for the Thread class that solves this problem in a more reasonable way.
- The ofPlatform() method is used to build a Thread instance, where the Platform Thread is actually the thread instance introduced in JDK1.0, the normal user thread
- The ofVirtual() method is used to build the VirtualThread instance, that is, to build the coroutine instance
The chain of all Setter methods for these two builder instances expands as follows.
One thing that can be found here is that the builder is reusable. If you want to use the builder to create the same batch of threads or concurrent threads with the same parameter settings, you can set the name(String prefix, long start) method to define the name prefix of the thread or concurrent thread and a number greater than or equal to 0. Call the Builder#unstarted(Runnable task) method repeatedly to create a batch of The name of the thread or concurrent thread is set to prefix + start, prefix + (start + 1), prefix + (start + 2), and so on. The creation of a thread is basically as simple as this, and the start() method is called directly if it is running.
Currently it is not possible to compile the above classes in the mainstream IDE, so they can only be compiled and run using the tools in that JDK directory as follows.
Here you can also see that the daemon flag of all concurrent instances is true by default and cannot be modified.
If you use the Loom project from a tasting perspective, you can get an early peek at how JVM developers are developing based on the major feature of concurrency, which can help a lot to increase interest in learning the JDK kernel code. From the current point of view, the implementation of the Loom project for the concurrency RELEASE version is estimated to have a lot of features to improve, including the stability of the new API, and whether the concurrency can be ported to the original JUC class library to use (the current Loom-JDK-18+9 did not modify the original thread pool and other class libraries) and other issues need to be resolved, so in the process of maintaining concern quietly wait for it.