Difference Between Thread and Virtual Thread in Java – Java中线程和虚拟线程的区别

最后修改: 2020年 3月 18日

中文/混合/英文(键盘快捷键：t)

1. Introduction

1.绪论

In this tutorial, we’ll show the difference between traditional threads in Java and the virtual threads introduced in Project Loom.

在本教程中，我们将展示Java中的传统线程与Project Loom中介绍的虚拟线程的区别。

Next, we’ll share several use cases for virtual threads and the APIs that the project has introduced.

接下来，我们将分享虚拟线程的几个用例以及该项目引入的API。

Before we start, we need to note this project is under active development. We’ll run our examples on early access loom VM: openjdk-15-loom+4-55_windows-x64_bin.

在我们开始之前，我们需要注意这个项目正在积极开发中。我们将在早期访问的loom VM上运行我们的例子：openjdk-15-loom+4-55_windows-x64_bin。

Newer versions of the builds are free to change and break current APIs. That being said, there was already a major change in the API, as the previously used java.lang.Fiber class has been removed and replaced with the new java.lang.VirtualThread class.

新版本的构建可以自由改变和破坏当前的API。也就是说，API已经发生了重大变化，之前使用的java.lang.Fiber类已经被移除，并被新的java.lang.VirtualThread类所取代。

2. High-Level Overview of Thread vs. Virtual Thread

2.线程与虚拟线程的高层概述

At a high level, a thread is managed and scheduled by the operating system, while a virtual thread is managed and scheduled by a virtual machine. Now, to create a new kernel thread, we must do a system call, and that’s a costly operation.

在高层次上，线程是由操作系统管理和调度的，而虚拟线程是由虚拟机管理和调度的。现在，要创建一个新的内核线程，我们必须进行系统调用，而这是一个昂贵的操作。

That’s why we’re using thread pools instead of reallocating and deallocating threads as needed. Next, if we’d like to scale our application by adding more threads, due to the context switching and their memory footprint, the cost of maintaining those threads may be significant and affect the processing time.

这就是为什么我们要使用线程池而不是根据需要重新分配和删除线程。接下来，如果我们想通过添加更多的线程来扩展我们的应用程序，由于上下文切换和它们的内存占用，维护这些线程的成本可能会很高，并影响处理时间。

Then, usually, we don’t want to block those threads, and this results in usages of non-blocking I/O APIs and asynchronous APIs, which might clutter our code.

那么，通常情况下，我们不想阻塞这些线程，这就导致了对非阻塞I/O API和异步API的使用，这可能会使我们的代码变得混乱。

On the contrary, virtual threads are managed by the JVM. Therefore, their allocation doesn’t require a system call, and they’re free of the operating system’s context switch. Furthermore, virtual threads run on the carrier thread, which is the actual kernel thread used under-the-hood. As a result, since we’re free of the system’s context switch, we could spawn many more such virtual threads.

相反，虚拟线程是由JVM管理的。因此，他们的分配不需要系统调用，而且他们不需要操作系统的上下文切换。此外，虚拟线程是在载体线程上运行的，而载体线程是在内部使用的实际内核线程。因此，由于我们摆脱了系统的上下文切换，我们可以衍生出更多这样的虚拟线程。

Next, a key property of virtual threads is that they don’t block our carrier thread. With that, blocking a virtual thread is becoming a much cheaper operation, as the JVM will schedule another virtual thread, leaving the carrier thread unblocked.

接下来，虚拟线程的一个关键属性是，它们不会阻塞我们的载体线程。有了这个，阻塞一个虚拟线程就变成了一个更便宜的操作，因为JVM会安排另一个虚拟线程，让载体线程不受阻塞。

Ultimately, we wouldn’t need to reach out for NIO or Async APIs. This should result in more readable code that is easier to understand and debug. Nevertheless, the continuation can potentially block a carrier thread — specifically, when a thread calls a native method and performs blocking operations from there.

最终，我们就不需要接触NIO或Async APIs了。这应该会产生更多可读的代码，更容易理解和调试。尽管如此，延续有可能会阻塞载波线程–具体来说，当线程调用本地方法并从那里执行阻塞操作时。

3. New Thread Builder API

3.新的线程生成器API

In Loom, we got the new builder API in the Thread class, along with several factory methods. Let’s see how we can create standard and virtual factories and make use of them for our thread execution:

在Loom中，我们在Thread类中得到了新的构建器API，同时还有一些工厂方法。让我们看看我们如何创建标准和虚拟工厂，并利用它们来执行线程。

Runnable printThread = () -> System.out.println(Thread.currentThread());
        
ThreadFactory virtualThreadFactory = Thread.builder().virtual().factory();
ThreadFactory kernelThreadFactory = Thread.builder().factory();

Thread virtualThread = virtualThreadFactory.newThread(printThread);
Thread kernelThread = kernelThreadFactory.newThread(printThread);

virtualThread.start();
kernelThread.start();

Here’s the output of the above run:

下面是上述运行的输出。

Thread[Thread-0,5,main]
VirtualThread[<unnamed>,ForkJoinPool-1-worker-3,CarrierThreads]

Here, the first entry is the standard toString output of the kernel thread.

这里，第一个条目是内核线程的标准toString输出。

Now, we see in the output that the virtual thread has no name, and it’s executing on a worker thread of the Fork-Join pool from the CarrierThreads thread group.

现在，我们在输出中看到，这个虚拟线程没有名字，它是在CarrierThreads线程组的Fork-Join池的一个工人线程上执行。

As we can see, regardless of the underlying implementation, the API is the same, and that implies we could easily run existing code on the virtual threads.

我们可以看到，无论底层实现如何，API都是一样的，这意味着我们可以很容易地在虚拟线程上运行现有代码。

Also, we don’t need to learn a new API to make use of them.

另外，我们不需要学习新的API来利用它们。

4. Virtual Thread Composition

4.虚拟线程组成

It is a continuation and a scheduler that, together, make up a virtual thread. Now, our user-mode scheduler may be any implementation of the Executor interface. The above example has shown us that, by default, we run on the ForkJoinPool.

它是一个延续和一个调度器，它们共同构成了一个虚拟线程。现在，我们的用户模式调度器可以是Executor接口的任何实现。上面的例子已经告诉我们，默认情况下，我们运行在ForkJoinPool上。

Now, similarly to a kernel thread – which can be executed on the CPU, then parked, rescheduled back, and then resumes its execution – a continuation is an execution unit that can be started, then parked (yielded), rescheduled back, and resumes its execution in that same way from where it left off and still be managed by a JVM instead of relying on an operating system.

现在，类似于内核线程–它可以在CPU上执行，然后停放，重新安排时间，然后恢复执行–延续是一个执行单元，它可以被启动，然后停放（屈服），重新安排时间，并以同样的方式从它离开的地方恢复执行，仍然由JVM管理，而不是依靠操作系统。

Note that the continuation is a low-level API, and that programmers should to use higher-level APIs like the builder API to run virtual threads.

请注意，continuation是一个低级别的API，程序员应该使用更高级别的API，如构建器API来运行虚拟线程。

However, to show how it’s working under-the-hood, now we’ll run our experimental continuation:

然而，为了显示它是如何在内部工作的，现在我们将运行我们的实验性延续。

var scope = new ContinuationScope("C1");
var c = new Continuation(scope, () -> {
    System.out.println("Start C1");
    Continuation.yield(scope);
    System.out.println("End C1");
});

while (!c.isDone()) {
    System.out.println("Start run()");
    c.run();
    System.out.println("End run()");
}

Here’s the output of the above run:

下面是上述运行的输出。

Start run()
Start C1
End run()
Start run()
End C1
End run()

In this example, we ran our continuation and, at some point, decided to stop the processing. Then once we re-ran it, our continuation continued from where it left off. By the output, we see that the run() method was called twice, but the continuation was started once and then continued its execution on the second run from where it left off.

在这个例子中，我们运行了我们的延续程序，并在某个时刻决定停止处理。然后，一旦我们重新运行，我们的延续就从它离开的地方继续。通过输出，我们看到run()方法被调用了两次，但是continuation被启动了一次，然后在第二次运行时从它离开的地方继续执行。

This is how blocking operations are meant to be processed by the JVM. Once a blocking operation happens, the continuation will yield, leaving the carrier thread unblocked.

这就是JVM要处理的阻塞操作的方式。一旦发生阻塞操作，延续就会屈服，让载体线程不受阻塞。

So, what happened is that our main thread created a new stack frame on its call stack for the run() method and proceeded with the execution. Then, after the continuation yielded, the JVM saved the current state of its execution.

因此，发生的情况是，我们的主线程在其调用堆栈上为run()方法创建了一个新的堆栈帧并继续执行。然后，在延续产生后，JVM保存了其执行的当前状态。

Next, the main thread has continued its execution as if the run() method returned and continued with the while loop. After the second call to continuation’s run method, the JVM restored the state of the main thread to the point where the continuation has yielded and finished the execution.

接下来，主线程已经继续执行，就像run()方法返回并继续while循环一样。在第二次调用continuation的run方法后，JVM将主线程的状态恢复到continuation已经屈服并完成执行的位置。

5. Conclusion

5.总结

In this article, we discussed the difference between the kernel thread and the virtual thread. Next, we showed how we could use a new thread builder API from Project Loom to run the virtual threads.

在这篇文章中，我们讨论了内核线程和虚拟线程之间的区别。接下来，我们展示了如何使用Project Loom的新线程构建器API来运行虚拟线程。

Finally, we showed what a continuation is and how it works under-the-hood. We can further explore the state of Project Loom by inspecting the early access VM. Alternatively, we can explore more of the already standardized Java concurrency APIs.

最后，我们展示了什么是continuation以及它是如何在内部工作的。我们可以通过检查早期访问虚拟机进一步探索Project Loom的状态。另外，我们还可以探索更多已经标准化的Java并发性API。