项目织机：使用虚拟线程时，什么使性能更好？

asynchronous multithreading java java-loom project-loom

2022-09-01 17:36:58

为了在这里提供一些背景，我已经关注Project Loom一段时间了。我读过《织布机的状态》。我做过异步编程。

异步编程（由 Java NIO 提供）在任务等待时将线程返回到线程池，并且它竭尽全力不阻塞线程。这带来了很大的性能提升，我们现在可以处理更多的请求，因为它们不受操作系统线程数量的直接约束。但我们在这里失去的是背景。同一任务现在不仅与一个线程关联。一旦我们将任务与线程分离，所有上下文都将丢失。异常跟踪不能提供非常有用的信息，调试也很困难。

在 Project Loom 中，虚拟线程成为并发的单一单元。现在，您可以在单个虚拟线程上执行单个任务。

到目前为止，一切都很好，但文章继续说，在Project Loom：

一个简单的同步Web服务器将能够处理更多的请求，而无需更多的硬件。

我不明白我们如何通过 Project Loom 而不是异步 API 获得性能优势？异步 API：s 确保不让任何线程处于空闲状态。那么，Project Loom 做了什么来使其比异步 API：s 更高效、更高性能呢？

编辑

让我重新表述这个问题。假设我们有一个http服务器，它接受请求，并使用支持持久性数据库执行一些粗略操作。比方说，这个http服务器处理了很多请求 - 100K RPM。实现此目的的两种方法：

HTTP 服务器具有专用的线程池。当请求传入时，线程将任务向上传递，直到它到达数据库，其中任务必须等待来自DB的响应。此时，线程返回到线程池并继续执行其他任务。当 DB 响应时，它将再次由线程池中的某个线程处理，并返回 HTTP 响应。
HTTP服务器只是为每个请求生成虚拟线程。如果存在 IO，则虚拟线程仅等待任务完成。然后返回 HTTP 响应。基本上，虚拟线程没有池化业务。

假设硬件和吞吐量保持不变，任何一种解决方案在响应时间或处理更多吞吐量方面都会比另一种解决方案更好吗？

我的猜测是，w.r.t性能不会有任何区别。

答案 1

我们没有比异步 API 更好的好处。我们可能获得的是类似于异步的性能，但使用同步代码。

答案 2

@talex的答案说得很清楚。进一步添加它。

Loom更多的是关于本机并发抽象，它还可以帮助人们编写异步代码。鉴于它是一个VM级抽象，而不仅仅是代码级（就像我们迄今为止一直在做的事情等），它允许一个人实现异步行为，但具有减少样板。CompletableFuture

对于织布机，更强大的抽象是救世主。我们已经反复看到，关于语法糖的抽象如何使一个人有效地编写程序。无论是JDK8中的FunctionalInterfaces，还是Scala中的理解。

使用织机，无需链接多个ComppletableFuture（以节省资源）。但是可以同步编写代码。随着每次遇到阻塞操作（ReentantLock，i / o，JDBC调用），虚拟线程都会被停放。而且由于这些是轻量级线程，因此上下文切换更便宜，从而将自己与内核线程区分开来。

当被阻止时，实际的承载线程（运行虚拟线程的 -body）会被吸引来执行其他一些虚拟线程的运行。因此，实际上，承载线程不是闲置，而是执行其他一些工作。并在未停放时返回以继续执行原始虚拟线程。就像线程池的工作方式一样。但是在这里，你有一个单一的载体线程，以某种方式执行多个虚拟线程的主体，在阻塞时从一个线程切换到另一个。run

我们获得了与手动编写的异步代码相同的行为（以及性能），而是避免了执行相同操作的样板。

考虑一个Web框架的情况，其中有一个单独的线程池来处理i / o，另一个线程池用于执行http请求。对于简单的 HTTP 请求，可以从 http 池线程本身处理请求。但是，如果有任何阻塞（或）高 CPU 操作，我们会让此活动异步发生在单独的线程上。

此线程将从传入请求中收集信息，生成一个，并将其与管道链接（从数据库读取作为一个阶段，然后从中计算，然后从另一个阶段写回数据库案例，Web服务调用等）。每个阶段都是一个阶段，结果返回到 Web 框架。CompletableFutureCompletablFuture

当最终的未来完成时，Web框架使用结果中继回客户端。这就是和其他人一直在处理它的方式。在 http 线程处理池和每个请求的执行之间提供隔离。但是，如果我们更深入地研究这个问题，为什么我们要这样做呢？Play-Framework

一个核心原因是有效地利用资源。特别是阻止呼叫。因此，我们使用 etc 进行链接，以便在任何活动上都不会阻塞任何线程，并且我们用较少的线程数执行更多操作。thenApply

这很好，但相当冗长。调试确实是痛苦的，如果其中一个中间阶段出现异常，控制流就会变得干草线，从而导致进一步的代码来处理它。

使用Loom，我们编写同步代码，并让其他人决定在被阻止时该怎么做。而不是睡觉，什么都不做。