Java 21 神仙特性:虚拟线程使用指南(一)

发布时间:2023年12月29日

虚拟线程是由 Java 21 版本中实现的一种轻量级线程。它由 JVM 进行创建以及管理。虚拟线程和传统线程(我们称之为平台线程)之间的主要区别在于,我们可以轻松地在一个 Java 程序中运行大量、甚至数百万个虚拟线程。

由于虚拟线程的数量众多,也就赋予了 Java 程序强大的力量。虚拟线程适合用来处理大量请求,它们可以更有效地运行 “一个请求一个线程” 模型编写的 web 应用程序,可以提高吞吐量以及减少硬件浪费。

由于虚拟线程是 java.lang.Thread 的实现,并且遵守自 Java SE 1.0 以来指定 java.lang.Thread 的相同规则,因此开发人员无需学习新概念即可使用它们。

但是虚拟线程才刚出来,对我们来说有一些陌生。由于 Java 历来版本中无法生成大量平台线程(多年来 Java 中唯一可用的线程实现),已经让程序员养成了一套关于平台线程的使用习惯。这些习惯做法在应用于虚拟线程时会适得其反,我们需要摒弃。

此外虚拟线程和平台线程在创建成本上的巨大差异,也提供了一种新的关于线程使用的方式。Java 的设计者鼓励使用虚拟线程而不必担心虚拟线程的创建成本。

本文无意全面涵盖虚拟线程的每个重要细节,目的只是提供一套介绍性指南,以帮助那些希望开始使用虚拟线程的人充分利用它们。

本文完整大纲如下,

请大方使用同步阻塞 IO

虚拟线程可以显着提高以 “一个请求一个线程” 模型编写的 web 应用程序的吞吐量(注意不是延迟)。在这种模型中,web 应用程序针对每个客户端请求都会创建一个线程进行处理。因此为了处理更多的客户端请求,我们需要创建更多的线程。

在 “一个请求一个线程” 模型中使用平台线程的成本很高,因为平台线程与操作系统线程对应(操作系统线程是一种相对稀缺的资源),阻塞了平台线程,会让它无事可做一直处于阻塞中,这样就会造成很大的资源浪费。

然而,在这个模型中使用虚拟线程就很合适,因为虚拟线程非常廉价就算被阻塞也不会造成资源浪费。因此在虚拟线程出来后,Java 的设计者是建议我们应该以简单的同步风格编写代码并使用阻塞 IO。

举个例子,以下用非阻塞异步风格编写的代码是不会从虚拟线程中受益太多的,

CompletableFuture.supplyAsync(info::getUrl,?pool)
???.thenCompose(url?->?getBodyAsync(url,?HttpResponse.BodyHandlers.ofString()))
???.thenApply(info::findImage)
???.thenCompose(url?->?getBodyAsync(url,?HttpResponse.BodyHandlers.ofByteArray()))
???.thenApply(info::setImageData)
???.thenAccept(this::process)
???.exceptionally(t?->?{?t.printStackTrace();?return?null;?});

另一方面,以下用同步风格并使用阻塞 IO 编写的代码使用虚拟线程将受益匪浅,

try?{
???String?page?=?getBody(info.getUrl(),?HttpResponse.BodyHandlers.ofString());
???String?imageUrl?=?info.findImage(page);
???byte[]?data?=?getBody(imageUrl,?HttpResponse.BodyHandlers.ofByteArray());
???info.setImageData(data);
???process(info);
}?catch?(Exception?ex)?{
???t.printStackTrace();
}

并且上面的同步代码也更容易在调试器中调试、在分析器中分析或通过线程转储进行观察。要观察虚拟线程,可以使用 jcmd 命令创建线程转储,

jcmd?<pid>?Thread.dump_to_file?-format=json?<file>

用同步风格并使用阻塞 IO 风格编写的代码越多,虚拟线程的性能和可观察性就越好。而用异步非阻塞 IO 风格编写的程序或框架,如果每个任务没有专用一个线程,则无法从虚拟线程中获得显着的好处。

使用虚拟线程,我们因该避免将同步阻塞 IO 与异步非阻塞 IO 混为一谈。

避免池化虚拟线程

关于虚拟线程使用方面最难理解的一件事情就是,我们不应该池化虚拟线程。虽然虚拟线程具有与平台线程相同的行为,但虚拟线程和线程池其实是两种概念。

平台线程是一种稀缺资源,因为它很宝贵。越宝贵的资源就越需要管理,管理平台线程最常见的方法是使用线程池。

不过在使用线程池后,我们需要回答的一个问题,线程池中应该有多少个线程?最小线程数、最大线程数应该设置多少?这也是一个问题。

虚拟线程是一种非常廉价的资源,每个虚拟线程不应代表某些共享的、池化的资源,而应代表单一任务。在应用程序中,我们应该直接使用虚拟线程而不是通过线程池使用它。

那么我们应该创建多少个虚拟线程嘞?答案是不必在乎虚拟线程的数量,我们有多少个并发任务就可以有多少个虚拟线程。

如下是一段提交任务的代码,将每个任务都提交到线程池中执行,在 Java 21 以后,不建议再使用共享线程池执行器,代码如下,

Future<ResultA>?f1?=?sharedThreadPoolExecutor.submit(task1);
Future<ResultB>?f2?=?sharedThreadPoolExecutor.submit(task2);
//?...?use?futures

建议使用虚拟线程执行器,代码如下,

try?(var?executor?=?Executors.newVirtualThreadPerTaskExecutor())?{
???Future<ResultA>?f1?=?executor.submit(task1);
???Future<ResultB>?f2?=?executor.submit(task2);
???//?...?use?futures
}

上面代码虽然仍使用 ExecutorService,但从 Executors.newVirtualThreadPerTaskExecutor() 方法返回的执行器不再使用线程池。它会为每个提交的任务都创建一个新的虚拟线程。

此外,ExecutorService 本身是轻量级的,我们可以像创建任何简单对象一样直接创建一个新的 ExecutorService 对象而不必考虑复用。

这使我们能够依赖 Java 19 中新添加的 ExecutorService.close() 方法和 try-with-resources 语法糖。在 try 块末尾隐式调用 ExecutorService.close() 方法,会自动等待提交给 ExecutorService 的所有任务(即 ExecutorService 生成的所有虚拟线程)终止。

对于广播场景来说,使用 Executors.newVirtualThreadPerTaskExecutor() 比较合适,在这种场景中,希望同时对不同的服务执行多个传出调用,并且方法结束时就关闭线程池,代码如下,

void?handle(Request?request,?Response?response)?{
????var?url1?=?...
????var?url2?=?...

????try?(var?executor?=?Executors.newVirtualThreadPerTaskExecutor())?{
????????var?future1?=?executor.submit(()?->?fetchURL(url1));
????????var?future2?=?executor.submit(()?->?fetchURL(url2));
????????response.send(future1.get()?+?future2.get());
????}?catch?(ExecutionException?|?InterruptedException?e)?{
????????response.fail(e);
????}
}

String?fetchURL(URL?url)?throws?IOException?{
????try?(var?in?=?url.openStream())?{
????????return?new?String(in.readAllBytes(),?StandardCharsets.UTF_8);
????}
}

针对广播模式和其他常见的并发模式,如果希望有更好的可观察性,建议使用结构化并发。这是 Java 21 中新出的特性,这里给大家卖个关子,我将在后续进行讲解。

根据经验来说,如果我们的应用程序从未经历 1 万的并发访问,那么它不太可能从虚拟线程中受益。一方面它负载太轻而不需要更高的吞吐量,一方面并发请求任务也不够多。

参考资料

  • https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html#GUID-E695A4C5-D335-4FA4-B886-FEB88C73F23E

最后说两句

针对虚拟线程的使用,相信大家心里已经有了答案。虚拟线程不同于平台线程,它非常廉价,Java 的设计者鼓励我们直接使用虚拟线程,而无需池化,也不必担心过多的虚拟现场会影响性能。

事实上,虚拟现场就是为了解决同步阻塞 IO 对硬件的资源利用率不够高这一问题。

文章来源:https://blog.csdn.net/Wayn111/article/details/135258696
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。