问题标签 [java-loom]

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

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

所以问题是：

1. 当Loom在生产中发布时，它不会让Netty有点过时吗？

2. 如果我们在Java中有Fibers和Continuations，我们可以编写漂亮的Sync代码并且可以在没有Netty的情况下使用C10K+吗？

3. 在Loom生产发布后，在编写Async代码和使用Netty方面，性能或解决C10K+有什么优势吗？

我知道Netty不仅仅是响应式/事件循环框架，它还具有各种协议的所有编解码器，无论如何，这些实现无论如何都会有用，即使是在之后。

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

异步编程（由 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.

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

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

我已经从https://jdk.java.net/loom/下载了早期发布版本，并且 java 启动了，但是运行Class.forName("java.lang.Fiber")并且Class.forName("java.lang.FiberScope")不起作用。是否有需要包含的标志/罐子？