Является ли Java 8 потоковая лень бесполезной на практике?

у меня есть реальный пример из нашей базы кода, так как я собираюсь упростить его, не совсем уверен, что вам это понравится или полностью понять...

у нас есть служба, которая нуждается в List<CustomService>, Я должен назвать это. Теперь, чтобы вызвать его, я иду в базу данных (намного проще, чем реальность) и получаю List<DBObject>, чтобы получить List<CustomService> из этого есть некоторые тяжелые преобразования, которые необходимо сделать.

и вот мой выбор, преобразование на месте и передать список. Простой, но, вероятно, не оптимальным. Второй вариант, рефакторинг службы, чтобы принять List<DBObject> и Function<DBObject, CustomService>. И это звучит тривиально, но это позволяет лень (между прочим). Эта служба может иногда нуждаться только в нескольких элементах из этого списка, или иногда max некоторым свойством и т. д. - таким образом, мне не нужно делать тяжелую трансформацию для все элементы, где Stream API тяга на основе лени победитель.

до того, как потоки существовали, мы использовали guava. Это было Lists.transform( list, function) это тоже было лениво.

это не фундаментальная особенность потоков как таковых, это могло бы быть сделано даже без гуавы, но это намного проще. Пример здесь приведен с findFirst велик и простейший для понимания; в этом весь смысл лени, элементы тянутся только тогда, когда это необходимо, они не передаются от промежуточной операции к другой кусками, а проходят от одной стадии к другой за раз.

лень может быть очень полезно для пользователей вашего API, особенно когда конечный результат Stream оценка конвейера может быть очень большой!

простой пример -Files.lines метод в самом API Java. Если вы не хотите читать весь файл в память и вам нужен только первый N строки, то просто написать:

Stream<String> stream = Files.lines(path); // lazy operation

List<String> result = stream.limit(N).collect(Collectors.toList()); // read and collect

вы правы, что не будет пользы от map().reduce() или map().collect(), но есть довольно очевидное преимущество с findAny() findFirst(), anyMatch(), allMatch(), etc. В принципе, любая операция, которая может быть закорочена.

один интересный случай использования, который не был упомянут, - это произвольный состав операций над потоками, поступающими из разных частей базы кода, реагирующими на различные виды бизнеса или технические требования.

например, скажем, у вас есть приложение, где некоторые пользователи могут видеть все данные, но некоторые другие пользователи могут видеть только часть его. Часть кода, которая проверяет разрешения пользователя, может просто наложить фильтр на любой передаваемый поток о.

без ленивых потоков эта же часть кода может фильтровать уже реализованную полную коллекцию, но это может быть дорого, без реальной выгоды.

кроме того, та же часть кода может захотеть добавить свой фильтр к источнику данных, но теперь он должен знать, поступают ли данные из базы данных, поэтому он может наложить дополнительное предложение WHERE или какой-либо другой источник.

с ленивыми потоками, это фильтр, который может быть реализовано всегда так. Фильтры, наложенные на потоки из базы данных, могут преобразовываться в вышеупомянутое предложение WHERE с очевидным повышением производительности по сравнению с фильтрацией коллекций в памяти в результате чтения всей таблицы.

Итак, лучшая абстракция, лучшая производительность, лучшая читаемость кода и ремонтопригодность, звучит как победа для меня. :)

хороший вопрос.

предполагая, что вы пишете идеальный код учебника, разница в производительности между правильно оптимизирован for и stream не заметно (потоки, как правило, немного лучше загружаются классом, но в большинстве случаев разница не должна быть заметна).

рассмотрим следующий пример.

// Some lengthy computation
private static int doStuff(int i) {
    try { Thread.sleep(1000); } catch (InterruptedException e) { }
    return i;
}

public static OptionalInt findFirstGreaterThanStream(int value) {
    return IntStream
            .of(MY_INTS)
            .map(Main::doStuff)
            .filter(x -> x > value)
            .findFirst();
}

public static OptionalInt findFirstGreaterThanFor(int value) {
    for (int i = 0; i < MY_INTS.length; i++) {
        int mapped = Main.doStuff(MY_INTS[i]);
        if(mapped > value){
            return OptionalInt.of(mapped);
        }
    }
    return OptionalInt.empty();
}

учитывая вышеуказанные методы, следующий тест должен показать, что они выполняются примерно в том же время.

public static void main(String[] args) {
    long begin;
    long end;

    begin = System.currentTimeMillis();
    System.out.println(findFirstGreaterThanStream(5));
    end = System.currentTimeMillis();
    System.out.println(end-begin);

    begin = System.currentTimeMillis();
    System.out.println(findFirstGreaterThanFor(5));
    end = System.currentTimeMillis();
    System.out.println(end-begin);
}

OptionalInt[8]

5119

OptionalInt[8]

5001

в любом случае, мы проводим большую часть времени в doStuff метод. Допустим, мы хотим добавить больше нитей в смеси.

настройка метода stream тривиальна (учитывая, что ваши операции отвечают предварительным условиям параллельных потоков).

public static OptionalInt findFirstGreaterThanParallelStream(int value) {
    return IntStream
            .of(MY_INTS)
            .parallel()
            .map(Main::doStuff)
            .filter(x -> x > value)
            .findFirst();
}

достижение того же поведения без потоков может быть сложной.

public static OptionalInt findFirstGreaterThanParallelFor(int value, Executor executor) {
    AtomicInteger counter = new AtomicInteger(0);

    CompletableFuture<OptionalInt> cf = CompletableFuture.supplyAsync(() -> {
        while(counter.get() != MY_INTS.length-1);
        return OptionalInt.empty();
    });

    for (int i = 0; i < MY_INTS.length; i++) {
        final int current = MY_INTS[i];
        executor.execute(() -> {
            int mapped = Main.doStuff(current);
            if(mapped > value){
                cf.complete(OptionalInt.of(mapped));
            } else {
                counter.incrementAndGet();
            }
        });
    }

    try {
        return cf.get();
    } catch (InterruptedException | ExecutionException e) {
        e.printStackTrace();
        return OptionalInt.empty();
    }
}

тесты выполняются примерно в то же время снова.

public static void main(String[] args) {
    long begin;
    long end;

    begin = System.currentTimeMillis();
    System.out.println(findFirstGreaterThanParallelStream(5));
    end = System.currentTimeMillis();
    System.out.println(end-begin);

    ExecutorService executor = Executors.newFixedThreadPool(10);
    begin = System.currentTimeMillis();
    System.out.println(findFirstGreaterThanParallelFor(5678, executor));
    end = System.currentTimeMillis();
    System.out.println(end-begin);

    executor.shutdown();
    executor.awaitTermination(10, TimeUnit.SECONDS);
    executor.shutdownNow();
}

OptionalInt[8]

1004

OptionalInt[8]

1004

в заключение, хотя мы не выжимаем большое преимущество производительности из потоков (учитывая, что вы пишете отличный многопоточный код в своем for alternative), сам код имеет тенденцию быть больше ремонтопригодный.

a (немного не по теме) последнее примечание:

как и в языках программирования, абстракции более высокого уровня (streams по отношению к fors) сделать материал проще разрабатывать за счет производительности. Мы не перешли от ассемблера к процедурным языкам и к объектно-ориентированным языкам, поскольку более поздние предлагали более высокую производительность. Мы переехали, потому что это сделало нас более продуктивными (развивайте то же самое по более низкой цене). Если вы можете получить такая же производительность из потока, как и с for и правильно написал многопоточный код, я бы сказал, что это уже победа.

non-lazy реализация будет обрабатывать все входные данные и собирать выходные данные в новую коллекцию для каждой операции. Очевидно, что это невозможно для неограниченных или достаточно больших источников, потребляющих память в противном случае и излишне потребляющих память в случае сокращения и короткого замыкания, поэтому есть большие преимущества.