Reactor中 publishOn 与 subscribeOn的区别

publishOn 和 subscribeOn

publishOn 和 subscribeOn。这两个方法的作用是指定执行 Reactive Streaming 的 Scheduler（可理解为线程池），不过这两个方法是用的场景是不相同的.

为何需要指定执行 Scheduler 呢？一个显而易见的原因是：组成一个反应式流的代码有快有慢，可能你的下游接口RT是不同的。如果将这些功能都放在一个线程里执行，快的就会被慢的影响，所以需要相互隔离。这是这两个方法应用的最典型的场景。

Scheduler

先介绍 Scheduler 这个概念。在 Reactor 中，Scheduler 用来定义执行调度任务的抽象。可以简单理解为线程池，但其实际作用要更多。Scheduler 的实现包括：

Schedulers.elastic(): 调度器会动态创建工作线程，线程数无上界
Execturos.newCachedThreadPool()
当前线程，通过 Schedulers.immediate()方法来创建。
单一的可复用的线程，通过 Schedulers.single()方法来创建。
使用对并行操作优化的线程池，通过 Schedulers.parallel()方法来创建。其中的线程数量取决于 CPU 的核的数量。该调度器适用于计算密集型的流的处理。
使用支持任务调度的调度器，通过 Schedulers.timer()方法来创建。
从已有的 ExecutorService 对象中创建调度器，通过 Schedulers.fromExecutorService()方法来创建。

Mono<Void> fluxToBlockingRepository(Flux<User> flux, 
                                    BlockingRepository<User> repository) {
    return flux
            .publishOn(Schedulers.elastic())
            .doOnNext(repository::save)
            .then();
}

Flux<User> blockingRepositoryToFlux(BlockingRepository<User> repository)  {
    return Flux.defer(() -> Flux.fromIterable(repository.findAll()))
               .subscribeOn(Schedulers.elastic());
}

这里的 repository 的类型是BlockingRepository，通常指的是会导致线程阻塞的IO操作

在第一个例子中，在执行了publishOn(Schedulers.elastic()) 之后，repository::save就会被 Schedulers.elastic()定义的线程池所执行。

而在第二个例子中，subscribeOn(Schedulers.elastic()) 的作用类似。它使得 repository.findAll()（也包括 Flux.fromIterable）的执行发生在 Schedulers.elastic()所定义的线程池中。

从上面的描述看，publishOn和subscribeOn 的作用类似，那两者的区别又是什么？

两者的区别
简单说，两者的区别在于影响范围。publishOn 影响在其之后的 operator执行的线程池，而 subscribeOn 则会从源头影响整个执行过程。所以，publishOn 的影响范围和它的位置有关，而 subscribeOn的影响范围则和位置无关。

看个 publishOn 和 subscribeOn 同时使用的例子

Flux.just("tom"）
        .map(s -> {
            System.out.println("[map] Thread name: " + Thread.currentThread().getName());
            return s.concat("@mail.com");
        })
        .publishOn(Schedulers.newElastic("thread-publishOn"))
        .filter(s -> {
            System.out.println("[filter] Thread name: " + Thread.currentThread().getName());
            return s.startsWith("t");
        })
        .subscribeOn(Schedulers.newElastic("thread-subscribeOn"))
        .subscribe(s -> {
            System.out.println("[subscribe] Thread name: " + Thread.currentThread().getName());
            System.out.println(s);
        });

输出结果如下：

[map] Thread name: thread-subscribeOn-3
[filter] Thread name: thread-publishOn-4
[subscribe] Thread name: thread-publishOn-4
tom@mail.com

从上面的例子可以看出，subscribeOn 定义在publishOn之后，但是却从源头开始生效。而在 publishOn执行之后，线程池变更为 publishOn 所定义的。

实际用途
这里介绍 publishOn和 subscribeOn的一种实际用途，那就是反应式编程和传统的，会导致线程阻塞的编程技术混用的场景。其实开头两个例子已经解释了这个场景。

在第一个 publishOn 的例子中，repository::save 会导致线程阻塞，为了避免造成对其它反应式操作的影响，便使用 publishOn 改变其执行线程。

在第二个 subscribeOn 的例子中，repository.findAll() 会导致线程阻塞。但是其是源头的 publisher，因此不能使用 publishOn 改变其执行线程。这时就需要使用 subscribeOn，在源头上修改其执行线程。

这样，通过 publishOn 和 subscribeOn 就在反应式编程中实现了线程池隔离的目的，一定程度上避免了会导致线程阻塞的程序执行影响到反应式编程的程序执行效率。

coderlong

原创文章 132 获赞 23 访问量 3万+

关注私信