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

指令式编程模型,所谓指令式编程模型，需要我们通过代码发布指令，然后等待指令的执行以及指令执行带来的状态变化。我们还要根据目前的状态，来确定下一次要发布的指令，并且用代码把下一个指令表示出来。指令式编程模型关注的重点就在于控制状态。

如果指令式编程模型的逻辑是告诉计算机"该怎么做"，那么声明式的编程模型的逻辑就是告诉计算机"要做什么"。指令式编程模型的代码像是流水线作业的工程师，事无巨细，拧好每一个螺丝；而声明式的编程模型的代码，更像是稳坐在军帐中的军师，布置任务，运筹帷幄。通过回调函数，来实现成功、失败处理。

不过，回调函数的设计也有着天生的缺陷。这个缺陷，就是回调地狱（Callback Hell，常被译为回调地狱。为了更直观地表达，我更喜欢把它叫做回调堆挤）。什么意思呢？通常地，我们需要布置多个小的任务，才能完成一项大的任务。这些小任务还有可能是有因果关系的任务，这时候，就需要小任务的配合，或者按顺序执行。

业界也有很多努力，试图改善回调函数的使用困境。其中最出色也是影响最大的一个，就是反应式编程。

反应式编程的基本逻辑，仍然是告诉计算机"要做什么"；但是它的关注点转移到了数据的变化以及数据和变化的传递上，或者说，是转移到了对数据变化的反应上。所以，反应式编程的核心是数据流和变化传递。

在 Java 的反应式编程模型的设计里，数据的输出使用只有一个参数的 Flow.Publisher 来表示。

js 复制代码

@FunctionalInterface
public static interface Publisher<T> {
    public void subscribe(Subscriber<? super T> subscriber);
}

在 Flow.Publisher 的接口设计里，泛型 T 表示的就是数据的类型。数据输出的对象，是使用 Flow.Subscriber 来表示的。换句话说，数据的发布者通过授权订阅者，来实现数据从发布者到订阅者的传递。一个数据的发布者，可以有多个数据的订阅者。

除了最初的来源和最终的结局，数据表现还有一个过程，就是数据的传递。数据的传递这个过程，既包括接收输入数据，也包括发送输出数据。在数据传递这个环节，数据的内容可能会发生变化，数据的数量也可能会发生变化（比如，过滤掉一部分的数据，或者修改输入的数据，甚至替换掉输入的数据）。在 Java 的反应式编程模型的设计里，这样的过程是由 Flow.Processor 表示的。Flow.Processor 是一个扩展了 Flow.Publisher 和 Flow.Subscriber 的接口。所以，Flow.Processor 有两个数据类型，泛型 T 表述输入数据的类型，泛型 R 表述输出数据的类型。

js 复制代码

public static interface Processor<T,R> extends Subscriber<T>, Publisher<R> {
}

反应式编程模型的缺陷也很要命。其中最要命的缺陷，就是错误很难排查，这是异步编程的通病。而反应式编程模型的解耦设计，加剧了错误排查的难度，这会严重影响开发的效率，降低代码的可维护性。

协程的处理方式，消除了线程的等待。如果调用阻塞，就会把资源切换出去，执行其他的操作。这就节省了大量的计算资源，使得系统在阻塞的模式下，支持大规模的并发。如果指令式编程模型能够通过协程的方式支持大规模的并发，也许它是一个颠覆现有高并发架构的新技术。

此文章为9月Day12学习笔记，内容来源于极客时间《深入剖析 Java 新特性》