响应式编程肯定很优雅，但是小伙子，即使对于最次要的任务，它是否也会增加认知负担……必须有一种更简单的方法来实现。
众说纷纭：
基础架构逻辑/业务逻辑比率确实不好。让我想起了EJB 2.0实体。
我很少觉得有必要。在大多数情况下，即使不是更好，基于线程池的方法也一样好
在某些情况下，我仍然喜欢反应式模型。使用推送流非常优雅。但是复杂性太高了。
我的感觉完全一样。我对反应式编程的普及感到困惑。它使我成为处理流数据的利基工具，而不是第一选择。但是，这就是它的营销方式。就个人而言，我对Fibers感到非常兴奋。
不幸的是，就Java而言，如果您具有非阻塞堆栈，那么您真的想使用Spring WebFlux路由而不是MVC / JAX-RS，并且该框架强制您在方法签名中使用Reactor类型来获取性能。等待观察Fibers的影响。
也许，我们必须重新考虑我们的范式范围。流设计和参与者方法相结合可以解决软件工程中的许多问题。关键是要分开集成和运维逻辑！加上结构化并发。
您真的认为这很优雅吗？听起来像是对我的工作。尽管我们也使用了这种技术（如果确实需要），但是在Loom项目中，轻量级，虚拟线程和结构化并发会带来更好的效果。