标签: java-loom

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

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

随之而来的项目织机virtual threads成为单一的并发单元。现在您可以在单个virtual thread.

直到现在一切都很好，但文章继续指出，项目织机：

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

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

编辑

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

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

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

我的猜测是，与性能没有任何区别。

我可能错了，但据我所知，整个Reactive/Event Loop 的事情，尤其是Netty，是为了解决C10K+问题而发明的。它有明显的缺点，因为您的所有代码现在都变成了Async，带有丑陋的回调，无意义的堆栈跟踪，因此难以维护和推理。

带有 goroutines 的Go语言是一个解决方案，现在他们可以编写Sync代码并处理C10K+。所以现在Java提出了Loom，它基本上复制了Go的解决方案，很快我们将拥有Fibers和Continuations，并且将能够再次编写Sync代码。