Netty和Project Loom

Question

我可能错了，但据我所知，整个Reactive/Event Loop的概念，尤其是Netty，都是为解决C10K+问题而发明的。这种做法有明显的缺点，因为你所有的代码都变成了Async，代码中充满了丑陋的回调函数和无意义的堆栈跟踪，因此难以维护和理解。

Go语言通过goroutines提供了一种解决方案，现在他们可以编写Sync代码并处理C10K+问题。所以现在Java推出Loom，本质上复制了Go的解决方案，我们很快就会拥有Fibers和Continuations，然后可以再次编写Sync代码。

因此，问题来了：

1. 当Loom投入生产时，它不会让Netty变得有点过时吗？

2. 如果我们在Java中使用Fibers和Continuations，能否编写好的Sync代码，并解决C10K+问题而无需使用Netty？

在Loom正式发布后，编写异步代码并使用Netty是否有性能上的优势或解决了C10K+问题？

我了解到Netty不仅仅是一个反应式/事件循环框架，它还拥有各种协议的编解码器，在实现中也会有所帮助。

- bxq

---

R2DBC 0.8 Release Candidate 1已发布，这是一个Java规范，用于异步关系型数据库访问。该版本包括对PostgreSQL的支持，以及其他一些改进和修复。如果您有任何问题或反馈，请在GitHub上提交问题。 - bodrin

@bodrin 另外，https://github.com/netty/netty/issues/8439 - bxq

据我所知，在 Loom 中不会提供 continuations，它们是内部的。 - fps

@fps 在JVM内部？当Loom被合并到JVM中时，它们可能会被称为内部的，是的 ‍♂️ - bxq

@bxq 我的意思是它们不会通过公共API暴露出来。 - fps

Answer 1

我专注于Netty的响应式部分，因为您似乎主要想回答一般层面上的问题：

目前，反应式编程范例通常用于解决性能问题，而不是因为它们适合问题。这些问题应该完全通过项目Loom来解决。

然而，某些问题可能仍然需要采用反应式编程方法，因为它比命令式代码更容易理解。反应式框架通常是面向流的，并且非常适合于组合不同实体/数据流上的元素和操作。它们还通过提供程序/订阅者模型提供了简单明了的本地事件总线解决方案。在这种情况下，反应式模型可能仍然是最佳选择，具有高性能且比命令式方法更易读。但是，确实，项目Loom应该使所有由于本地语言结构缺乏更好支持而产生的“误用”都变得过时了。

- Frank Hopkins