项目织机虚拟线程会提高并行流的性能吗？

Question

这不是How do I write a correct micro-benchmark in Java?的副本

这个问题涉及到Project Loom设计和实现的核心，以及该项目是否能够加速Java并行流的性能。这个问题不是关于基准，而是关于项目织布机的意图。

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

try (var executorService = Executors.newThreadPerTaskExecutor(virtualThreadFactory)) {
    var candidates3 = LongStream.iterate(3, x -> x < count, x -> x + 2);
    time4 = System.currentTimeMillis();
    var primes3 = executorService.submit(() ->
        candidates3.parallel()
            .filter(candidate -> isPrime(candidate)).toArray()
    ).get();
    time5 = System.currentTimeMillis();
}

最终我在哪里得到输出(以毫秒为单位)

sequential time = 7546
parallel   time = 1289
virtual    time = 1388

一般来说，使用虚拟线程比使用普通的ForkJoinPool要慢。我是不是在某个地方犯了一些基本的错误或误解，或者Project Loom还没有与Java Streams集成？

Answer 1

好吧，我的感觉是

IIUC，虚拟线程的真正好处是当你有一个阻塞的I/O操作时。有了织布机，当你的虚拟线程阻塞时，底层的载体线程将继续执行其他任务。在Loom之前，没有进行这种区分-只有一种类型的线程-并且阻塞I/O对于高吞吐量的应用程序来说不是一个可行的选择，比如web服务器。

意味着虚拟线程不会在这个用例中给我带来我所希望的性能提升……

在我的实验中，我用来计算质数

1. 7397ms-顺序流
2. 1316 ms -并行流
3. 1392 ms -具有虚拟线程的执行服务上下文中的并行流
4. 4472 ms -具有

ms的虚拟线程-从流创建的虚拟线程

情况2和3在性能上非常接近，它们在误差范围内。

这不是I/O限制，而是纯粹的计算限制。并行流在这种情况下工作得特别好，而且很难(不可能？)做得更好。我对虚拟线程的期望是对虚拟线程如何优化的误解。现在我更清楚了。

如果我想展示虚拟线程相对于平台线程的性能优势，我需要找到一个更好的用例。

我的代码发布在loom-lab上，以防其他人想要验证我的结论。这是一个学习项目，我正在学习...