aoe2021-12-07虽然反应式编程编写起来复杂，但是因其是针对并发场景设计的，有机会还是很想体验一下威力，因为： 1. 数据传递时具有不可变的特性，天然支持线程安全； 2. 令人崩溃的多线程操作由 JDK 团队负责处理，降低了并发编程门槛 3. 《响应式架构 消息模式Actor实现与Scala.Akka应用集成》这本书中提到使用“反应式架构”的设计普通服务器的吞吐量可以轻松达到 300 ~ 500 万/秒（记不清具体数值了），有这么高的吞吐量很多公司的业务就不需要微服务了，相对编写微服务的代码，也算简单了很多； 4. 《Java编程方法论:响应式Spring Reactor 3设计与实现》这本书入门还是挺好的，跟着书中示例运行一遍代码，差不多就入门了。作者回复: 是的，现在看，反应式编程是高并发场景的主流选择。
共 8 条评论4
Calvin2021-12-07老师，这个感觉有点抽象和复杂，有没有什么现成的已经在使用的业务场景的例子可以介绍来看看吗？加深下印象。 PS：思考题 PR：https://github.com/XueleiFan/java-up/pull/18作者回复: 有时间看看Apache Spark, Akka, 或者Kafka。现在主流的高并发架构里，都有反应式的影子在。
2- bigben2021-12-09感觉这个api设计的不好理解也不合理，我觉得subscribe方法应该在subsciber上面，而不是publisher上面，太别扭了！
作者回复: 其实，这也许恰恰是精妙的地方。想一想数据流和控制权，可能感觉就好一点了。
1 
worry2021-12-08go语言本身就支持协程，go语言在云服务上的成功是不是能证明协程这种模式是未来呢。spring是强烈推荐反应式编程模式的。作者回复: 我想是的，但是还需要时间验证。
1
TableBear
2021-12-07协程看起来很强，不知道啥时候能用上呢作者回复: 下一个长期支持版可能就看到苗头了。
共 2 条评论1
Jxin2021-12-14以下仅个人观点，不一定对，只是明确的表达不同的观点。 1.如果讲究声明式编程的话 Digest.of() 不该传入成功与失败时的执行函数。使用方只感知 Digest.of() 这个目标，不关心内部的执行细节（包括成功失败的分支流转），对应成功失败走什么逻辑封装在 Digest 的子类或实现类。只要在有必要时才会打开 Digest 的子类去看对应的实现细节。 2.回调函数的写法应当遵循超文本的风格。仅包含，数据信息/执行某个动作/获取新的超文本(带有回调函数的实体)。如此一来，代码实现就不会存在逻辑上的堆积，将会以资源模型为载体各自独立收敛。如果你发现有避不开的堆积，可能不是回调函数的问题，而是你在这里缺失了某种资源模型。 3.反应式编程模型错误难排查的问题，靠链路追踪的日志体系其实可以缓解，没有指令式那么直观，但排查耗时也不会差很多。反倒是实现的结构降低了可读性，加剧了代码维护难度，这个问题比较大。同步写异步执行会是一个更舒服的方向，所以同样是提高性能，如果协程能满足需求，应该会更推崇协程。作者回复: 1. 声明式编程是一个大箩筐，有不同的偏好，反应式和回调式是不同的选择。 2. 也许吧，还不太明白资源模型和回调函数的结合。需要学习。 3. 反应式的可读性可能依赖于框架的选择，我看Akka的代码很舒服。
黑2021-12-14一直有个疑惑，新版的jdk使用flow的话，回调函数是否还是存放和唤醒逻辑是什么样的呢。作者回复: 没太明白这个问题。要不，你换个说法，看看我能不能理解你的问题？
ABC2021-12-07Java 的虚拟线程,尾调用优化等来自 OpenJDK的 loom 项目。刚去看了下,目前依然只支持 Mac 和 Linux 系统。老师,如果正式发布了,是否会内置到 JDK 中呢?作者回复: 是的， 会是JDK的一部分。
- ABC2021-12-07换成反应式增加了不少代码。之前看过一些Spring提供的反应式编程，但碍于生态问题，那会很难用到生产环境中，现在也许成熟多了。 在JavaScript里面，很早就用异步请求了，但很简单和方便。 说起回调地狱，可以去看看Flutter的嵌套地狱，还好在IDE端做了提示优化，不然很难分清哪个括号对应的代码。
作者回复: 异步一定要再封装一层， 否则太难用了。 JDK没有提供进一步的封装，就显得比较复杂。
kimoti2021-12-06感觉原来三行代码,换成响应式复杂了许多作者回复: 的确要复杂很多，不过可以再抽象出来一层简化。如果你看看Akka的设计，总体感觉是应用层的代码可以更少、更简单。