10 | Flow，是异步编程的终极选择吗？

范学雷

你好，我是范学雷。今天，我们讨论反应式编程。
反应式编程曾经是一个很热门的话题。它是代码的控制的一种模式。如果不分析其他的模式，我们很难识别反应式编程的好与坏，以及最合适它的使用场景。所以，我们今天的讨论，和以往有很大的不同。
除了反应式编程之外，我们还会花很大的篇幅讨论其他的编程模式，包括现在的和未来的。希望这样的安排，能够帮助你根据具体的场景，选择最合适的模式。
我们从阅读案例开始，先来看一看最传统的模式，然后一步一步地过渡到反应式编程，最后我们再来稍微聊几句 Java 尚未发布的协程模式。
阅读案例我想，你和我一样，无论是学习 C 语言，还是 Java 语言，都是从打印"Hello, world!"这个简单的例子开始的。我们再来看看这个我们熟悉的代码。
System.out.println("Hello, World!");
这段代码就是使用了最常用的代码控制模式：指令式编程模型。所谓指令式编程模型，需要我们通过代码发布指令，然后等待指令的执行以及指令执行带来的状态变化。我们还要根据目前的状态，来确定下一次要发布的指令，并且用代码把下一个指令表示出来。
上面的代码里，我们发布的指令就是：标准输出打印“Hello, World!”这句话。然后，我们就等待指令的执行结果，验证我们编写的代码有没有按照我们的指令工作。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入探讨了反应式编程模型在异步编程中的应用，强调了指令式编程模型的局限性和性能问题，并详细介绍了声明式编程模型和反应式编程的基本逻辑。文章提到了Java尚未发布的协程模式，并探讨了异步编程的挑战和解决方案。此外，还介绍了数据的控制和传递，展示了反应式编程模型的强大动力。然而，文章也指出了反应式编程模型的缺陷，包括错误排查困难和降低代码的可维护性。最后，展望了Java的协程模式对反应式编程模型的影响，以及对实现大规模并发系统的便利性。整体来看，本文通过对不同编程模式的比较，探讨了异步编程中的挑战和解决方案，为读者提供了深入了解异步编程的技术知识和应用实践的指导。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《深入剖析 Java 新特性》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(14)

最新
精选

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

收起评论