问题标签 [project-loom]

为了在这里提供一些背景信息，我已经关注项目织机一段时间了。我已经阅读了织机的状态。我做过异步编程。

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

随着项目的出现，virtual threads它成为了单一的并发单元。现在您可以在单个virtual thread.

到目前为止一切都很好，但文章继续说明，项目织机：

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

我不明白我们如何通过异步 API 获得项目织机的性能优势？asynchrounous APIs确保不要让任何线程空闲。那么，project loom 做了什么来使其比asynchronousAPI 更高效和高性能呢？

编辑

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

1. HTTP 服务器有一个专用的线程池。当一个请求进来时，一个线程将任务向上传送直到它到达DB，其中任务必须等待来自DB的响应。此时，线程返回线程池并继续执行其他任务。当 DB 响应时，它再次由线程池中的某个线程处理并返回 HTTP 响应。
2. HTTP 服务器只是virtual threads为每个请求生成。如果有 IO，虚拟线程只是等待任务完成。然后返回 HTTP 响应。基本上，没有针对virtual threads.

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

我的猜测是性能不会有任何差异。

Project Loom现在可以在Java 16的特殊早期版本中使用。

如果我要在缺少 Project Loom 技术的 Java 实现上运行基于 Loom 的应用程序，有没有办法在我的应用程序启动的早期优雅地检测到这一点？

我想写这样的代码：

我该如何实现一个projectLoomIsPresent()方法？

我Thread.sleep在试验或演示 Java 代码的并发性时使用。通过睡觉，我正在伪造一些需要一些时间的处理工作。

我想知道在Project Loom下这样做。

• 在Project Loom技术下使用虚拟线程（纤Thread.sleep程），我们可以同样使用吗？
• 休眠虚拟线程与休眠平台/内核线程有什么不同或值得注意的吗？

为了自学，我观看了 2020 年末与 Oracle 的 Ron Pressler 一起展示 Project Loom 技术的视频（此处，此处）。虽然很有启发性，但我不记得他解决过休眠线程的问题。

我知道 Java 尚未添加尾调用消除优化，并打算将其作为Project Loom的后期添加。相反，我的问题是：JIT 是否会完全优化递归方法调用并将它们转换为迭代形式？名义上这似乎是可能的，但相对困难，所以我猜他们是否会在某些文档中进行强烈描述，但我正在努力追踪有关该主题的任何内容。

作为后续，如果 JIT 确实消除了超出 Loom 中描述的某种形式的递归调用，那么它是如何出现在堆栈跟踪上的？

我第一次玩 Project Loom，我有一些代码

输出像

有没有办法告诉我每个虚拟线程正在运行哪个运营商线程？

是否ForkJoinPool-1-worker-11代表特定的运营商（平台）线程，或者它是否意味着其他东西？

我刚刚开始玩 Project Loom ......

鉴于 Java 代码似乎可以正常工作

当 IntelliJ 将其转换为 Kotlin 时，我得到

这似乎编译得很好，但是在执行时，控制台上没有打印任何内容？

Kotlin 和 Project Loom 之间是否存在一些潜在的不兼容性？

进一步的实验表明

不打印任何东西，但是

确实打印了预期的结果，所以 Kotlin 和虚拟线程之间存在根本不兼容的东西。然而，

不打印任何东西，所以还有其他问题在起作用......确实

不打印任何东西，但是

是否打印预期结果？还，

打印预期的结果，所以有一些奇怪的use？

这引出了问题

1. Project Loom 的设计/实现方式是否存在导致 Kotlin 出现问题的问题？
   • JDK-18 是否存在一些与 Kotlin 不兼容的问题？
2. Kotlin 的设计/实现方式是否存在无法与 Project Loom 互操作的问题？
   • Kotlin 是否存在一些与 JDK-18 不兼容的问题？

来自loom-lab，给出代码

我希望代码会catch打印RuntimeException消息，但事实并非如此。

是我希望太多，还是有一天会像我希望的那样工作？

为了回应 Stephen C 的惊人回答，我完全可以理解，在进一步探索后，我通过以下方式发现

和

我希望根据文档malcontent被卷入其中，但事实并非如此。因此，我很难对自己的期望进行推理。spawnExecutionException

我对 Project Loom 的大部分希望是，与函数式反应式编程不同，我可以再次依靠异常来做正确的事情，并对它们进行推理，这样我就可以预测会发生什么，而无需运行实验来验证真正发生的事情.

正如史蒂夫乔布斯（在 NeXT）曾经说过的那样：“它就是有效的”

到目前为止，我在 loom-dev@openjdk.java.net 上的帖子还没有得到回复……这就是我使用 StackOverflow 的原因。我不知道吸引 Project Loom 开发人员的最佳方式。

我正在我的loom-lab项目中试验虚拟线程，并想看看在执行并行流时虚拟线程是否比平台线程快，但实际上它似乎更慢。

最终我得到输出的地方（以毫秒为单位）

并且通常使用虚拟线程比常见的 ForkJoinPool 慢。我是否在某处犯了一些基本错误或误解，或者 Project Loom 尚未与 Java Streams 集成？

这不是我如何在 Java 中编写正确的微基准测试的副本？

问题涉及 Project Loom 设计和实现的核心，以及该项目是否能够加速 Java Parallel Streams 的性能。问题不在于基准测试，而在于 Project Loom 的意图。

我正在我的loom-lab项目中试验虚拟线程，并想看看在执行并行流时虚拟线程是否比平台线程快，但实际上它似乎更慢。

最终我得到输出的地方（以毫秒为单位）

并且通常使用虚拟线程比常见的 ForkJoinPool 慢。我是否在某处犯了一些基本错误或误解，或者 Project Loom 尚未与 Java Streams 集成？

我正在研究Project Loom是如何运作的，以及它能给我的公司带来什么样的好处。

所以我理解动机，对于基于标准 servlet 的后端，总是有一个执行业务逻辑的线程池，一旦线程因为 IO 而被阻塞，它除了等待什么也做不了。因此，假设我有一个具有单个端点的后端应用程序，该端点背后的业务逻辑是使用内部使用 InputStream 的 JDBC 读取一些数据，后者将再次使用阻塞系统调用（在 Linux 中为 read()）。所以如果我有 20000 个用户到达这个端点，我需要创建 200 个线程，每个线程等待 IO。

现在假设我将线程池切换为使用虚拟线程。根据 Ben Evans 在Going inside Java's Project Loom and virtual threads一文中的说法：

相反，当进行阻塞调用（例如 I/O）时，虚拟线程会自动放弃（或让出）它们的载体线程。

据我了解，如果我的操作系统线程数量等于 CPU 内核数量和无限数量的虚拟线程，所有操作系统线程仍将等待 IO，并且执行器服务将无法为虚拟线程分配新工作因为没有可用的线程来执行它。它与常规线程有何不同，至少对于操作系统线程，我可以将其扩展到数千以增加吞吐量。还是我只是误解了 Loom 的用例？提前致谢

添加在

我刚刚阅读了这个邮件列表：

虚拟线程喜欢阻塞 I/O。如果线程需要阻止 Socket 读取，那么这会释放底层内核线程以执行其他工作

我不确定我是否理解它，如果操作系统执行诸如读取之类的阻塞调用，则操作系统无法释放线程，出于这些目的，内核具有非阻塞系统调用，例如 epoll，它不会阻塞线程并立即返回有一些可用数据的文件描述符列表。上面的引用是否暗示在后台，如果调用它的线程是虚拟的，JVM 将用read非阻塞替换阻塞？epoll