启动1000万个虚拟线程需要多少时间？需要多少平台线程？

之前，在Java新特性专栏中，我们简单介绍了Java 21正式发布的虚拟线程。

昨天，正好看到一个讲解此内容的视频，非常不错，所以DD这里给大家翻译好了，感兴趣的可以看看。可以进一步了解虚拟线程。

什么是虚拟线程？一次启1000万个会怎么样？

该视频采用Chrome插件Youtube中文配音做了翻译+配音处理，如果您平时也有上油管看前沿视频的话，也可以装一个，可以有效的提高你的学习效率 ^_。

如果您当前环境不适合观看视频，也可以通过下面的文字内容学习。下面内容是我根据视频内容，总结的，会更简洁一些。

什么是虚拟线程

虚拟线程是在Java并发领域添加的一个新概念，那么虚拟线程到底是做什么用的呢？

根据JEP中的内容告诉我们，虚拟线程是一种轻量级线程，可以显著地帮助我们减少编写、维护、观察高吞吐量应用程序的工作量。它的实现目标有以下几点：

每个请求一个线程风格编写的程序，能够以接近最佳硬件利用率进行扩展。

什么是每个请求一个线程的风格？

对于HTTP服务器来说，这意味着每个HTTP请求都由它自己的线程处理。对于关系型数据库服务器来说，这意味着每个SQL事务也都由它自己的线程处理。如果您曾经使用过 Java EE 服务器，那么它就是这样工作的。所以，什么是每个请求一个线程的风格就是：一个请求 = 一个事务 = 一个线程。

那么，这个模型的成本是多少呢？ 要了解这个成本，您需要了解 Java 中线程的成本。平台线程和 CPU 使用率的成本。

Java 线程是在 Java 的早期版本中创建的，属于平台线程，也称为操作系统线程上的薄包装器。关于它们，您需要了解两件事。

平台线程需要将其调用堆栈存储在内存中
它是系统资源，启动平台线程大约需要一毫秒

事实上，平台线程是一种相当昂贵的资源。如何利用此类线程优化硬件利用率呢？

假设您的应用程序有 16 GB 的可用内存。除以 20 MB 的线程大小，这样的机器上就有 800 个线程的空间。假设这些线程正在执行一些 I/O，就像访问网络上的资源一样。假设该资源在 100 毫秒内被访问。准备请求和处理响应将在 10 纳秒的时间内完成。假设所有这些内存计算需要 1000 纳秒。这意味着在准备请求和处理响应之间存在一个大约 100000 的因素，以及获得响应所需的时间，在此期间您的线程就在那里什么都不做。所以如果你有 800 个这样的线程，那么CPU利用率只有可怜的0.8%。

如果你将内存加倍到 32 GB，那么CPU利用率可以达到1.3%，但这仍然很低。

反过来思考下，如果我们希望达到90%的CPU利用率。那么就需要 90000 个线程，启动它们需要 90秒，同时，还要消耗 1.8 TB 的内存。

很明显，平台线程的成本太高，无法以接近最佳的硬件利用率进行扩展。因此，我们需要另一种线程模型来解决这样的问题。

使基于经典 Java 线程的现有代码能够以最小更改代价来使用虚拟线程。

这一目标意味着可以把经典线程做的所有事情，轻松的转换为虚拟线程的处理方式来完成。这里涵盖了几个关键点。

虚拟线程可以运行任何Java代码或任何本机代码。
你不需要学习任何新概念。
但你需要忘掉某些想法，比如：
- 虚拟线程很便宜，比传统平台线程便宜大约 1,000 倍。
- 阻塞虚拟线程的成本也很低，因此试图避免阻塞虚拟线程是没有用的。
- 编写经典的阻塞代码是可以的，这是一个好消息，因为阻塞代码比异步代码更容易编写。此时，您可能想知道，池化虚拟线程是个好主意吗？嗯，答案是否定的。不要那样做。你只是在浪费时间。

关于虚拟线程还有两个好消息：线程局部变量也以同样的方式工作；同步也有效。关于同步有几件事需要说一下。虚拟线程仍然运行在平台线程之上，下面还有一个平台线程。不过，这个虚拟线程可以与其平台线程分离，以便这个平台线程可以运行另一个虚拟线程。什么时候才能脱离呢？虚拟线程一旦阻塞就可以与其平台线程分离。它可能会在I/O操作或同步操作上被阻止，或者可能会被置于睡眠状态。如果虚拟线程正在同步块内执行某些代码，则它无法与其平台线程分离。因此，在运行此同步代码块期间，它会阻塞平台线程。如果这个时间很短，那也没关系。无需恐慌，也无需采取任何措施来防止这种情况发生。如果这个时间很长，也就是说，如果它正在做一些长时间的I/O操作，那么情况就不太好了。您可以通过简单地将对 synchronized 的调用替换为可重入锁来防止这种情况发生。

深入研究编码

关于如何创建虚拟线程，在之前的Java 21新特性虚拟线程中有提到。通过Thread.ofVirtual()即可，比如：

Thread.ofVirtual()
        .name("didispace-virtual-thread")
        .start(runnable);

Tips：如果要创建平台线程，则可使用：Thread.ofPlatform()

虚拟线程工作在平台线程之上。您可能认为没有任何性能提升，只是产生了开销。那么到底是怎么回事呢？关于虚拟线程还有更多内容。下面一起来看看这段代码是如何运行的。

这段代码中，使用了流模式创建 10 个虚拟的、未启动的线程。这些线程正在运行的任务只是打印当前线程。然后，让它们休眠 10 毫秒，接着再次打印线程的名称。最后，启动这些未启动的线程并调用 join 方法以确保所有内容都可以在控制台上看到。

那么运行这段代码，您会发现这里发生了一些真正意想不到的事情。

这个ForkJoinPool的线程7，当它从睡眠状态回来时，它并没有继续运行在原来的平台线程上，而是跳转到了另外一个平台线程。如果您在自己的计算机上执行此操作，请确保启动足够的虚拟线程，因为您可能不会仅使用一两个线程来观察到这一点。

它在幕后是如何工作的

事实上，当虚拟线程由于某些操作而被阻塞时，相应的堆栈就会从其运行的平台线程移动到堆内存中。所以，现在这个平台线程可以自由地运行另一个虚拟线程。当这个任务收到可以继续运行的信号时，它的堆栈就会从堆移回平台线程，但不一定相同。所以，这就是阻塞虚拟线程的代价，将该虚拟线程的堆栈移动到主内存并返回。阻塞虚拟线程并不是免费无开销的，但它比阻塞平台线程要划算得多。