跳至主要內容

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

程序猿DD原创JavaJava大约 9 分钟

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

之前,在Java新特性专栏open in new window中,我们简单介绍了Java 21正式发布的虚拟线程open in new window

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

该视频采用Chrome插件Youtube中文配音open in new window做了翻译+配音处理,如果您平时也有上油管看前沿视频的话,也可以装一个,可以有效的提高你的学习效率 ^_^。如果您不方便查看这些内容,也可以关注我的视频号「程序猿DD」和B站open in new window,我会分享日常看到的精华学习资料,感兴趣的小伙伴根据自己平时习惯选择订阅即可。

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

什么是虚拟线程

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

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

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

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

对于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 的内存。

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

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

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

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

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

深入研究编码

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

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

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

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

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

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

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

它在幕后是如何工作的

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

Tips: 这段逻辑视频里有图形化的解释,推荐结合视频动画观看,会更容易理解。

令人高兴的是,JDK 的所有阻塞操作都已被重构以利用它。其中包括I/O操作、同步和Thread.sleep

需要多少平台线程来运行虚拟线程

关于这个问题,我们可以测试一下。让我创建虚拟线程并收集所有相应的平台线程名称。

该代码基本上启动了五个虚拟线程,然后使用一些代码提取池名称和平台线程名称。最后,它只是打印不同的统计信息、运行此代码所需的时间、CPU 上的核心数量、线程池数量,以及平台线程的数量。

那么让我运行这段代码,可以看到如下结果:

对于 5 个虚拟线程,它使用 3 个平台线程并花费 2 毫秒。

让我使用 10 个虚拟线程并再次运行代码。

对于 10 个线程,它仍然使用 3 个平台线程并花费了 4 毫秒。

让我使用 100 个虚拟线程并再次运行代码。

现在它使用 7 个平台线程。

让我们看看 1,000 个虚拟线程会发生什么。

它仍然使用 7 个平台线程。

试试10万个虚拟线程怎么样?

现在它使用 8 个平台线程,花费了 156 毫秒。

顺便说一句,即使这些线程没有做太多事情,只是一些字符串操作和在并发集中添加元素,您也可以看到运行所有这些线程只需要 156 毫秒。

现在让我增加到 100 万个线程。

花费了不到一秒的时间,并且仍然使用 8 个平台线程。

启动1000万个虚拟线程

我们尝试启动 1000 万个虚拟线程怎么样?你曾经尝试过这样做吗?在您的机器上启动 1000 万个平台线程?嗯,通常这是不可能的,但是使用虚拟线程,我们也许能够做到。我们可以获得如下结果:

这还只是在一台旧笔记本电脑上测试的结果,只需要不到 7 秒的时间,这真是太棒了!

这就是Java 中的虚拟线程!是不是很棒?那么,你是否已经开始升级Java 21并开始使用此特性来提升你的应用性能了呢?留言区一起聊聊吧。

码字不易,如果您喜欢本文,欢迎点赞、在看、转发支持一下。

上次编辑于:
贡献者: 程序猿DD