Реактивный почтовый индекс, не ленивый даже при использовании с отсрочкой - PullRequest
Новая
       16

Реактивный почтовый индекс, не ленивый даже при использовании с отсрочкой

0 голосов
/ 28 октября 2018

У меня есть этот код с каркасом реактора проекта, но это относится и к rxjava1, только что проверил его (предположительно для rxjava2), и я не могу найти причину, по которой оператор zipWith() оценивает свой параметр как текущий, даже если события отфильтрованызаранее и используется defer(). 

import reactor.core.publisher.Flux;

public class TestLazy {
    public static void main(String[] args) {
        Flux.just(1, 2, 3)
            .filter(s -> s > 4)
            .zipWith(Flux.defer(() -> Flux.just(get1(), get2(), get3())), (a, b) -> a + b)
            .subscribe(System.out::println);

        Flux.just(1, 2, 3)
            .filter(s -> s > 4)
            .flatMap(a -> Flux.defer(() -> Flux.just(fromFlatMap())))
            .subscribe(System.out::println);
    }

    private static int fromFlatMap() {
        System.out.println("from flatMap");
        return 0;
    }

    private static int get1() {
        System.out.println("get 1");
        return 1;
    }

    private static int get2() {
        System.out.println("get 2");
        return 2;
    }

    private static int get3() {
        System.out.println("get 3");
        return 3;
    }
}

Выход составляет 

get 1
get 2
get 3

Для flatMap() это не так.Почему это поведение?Спасибо

1 Ответ

0 голосов
/ 28 октября 2018

flatMap никогда не выполняет свою лямбду, потому что она никогда не получает никакого значения.

zipWith в текущих версиях различных библиотек всегда подписываются на оба своих источника, таким образом, побочные эффекты подписки из этих get s (println) запускаются, хотя в конце нет ничего, что можно сжать вместе.

...