заглянуть в параллельный поток для увеличения счетчика [dубликат]

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

И count() не может обрабатывать какие-либо элементы вообще, когда он может определить размер потока без обработки элементов. Поскольку это оптимизация, не сделанная в Java 8, но которая будет в Java 9, могут возникнуть сюрпризы при переключении на Java 9 и иметь код, основанный на count() обработке всех элементов. Это также связано с другими зависимыми от реализации деталями, например. даже в Java 9 эталонная реализация не сможет предсказать размер бесконечного источника потока в сочетании с limit, в то время как нет фундаментального ограничения, предотвращающего такое предсказание.

Поскольку peek позволяет «выполнять предоставленное действие для каждой операции терминала ", оно не требует обработки элементов, но будет выполнять действие, зависящее от необходимости операции терминала. Это означает, что вы должны использовать его с большой осторожностью, если вам нужна конкретная обработка, например. хотите применить действие ко всем элементам. Он работает, если операция терминала гарантирована для обработки всех элементов, но даже тогда вы должны быть уверены, что не следующий разработчик не изменит операцию терминала (или вы забудете этот тонкий аспект).

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

Итак, самая полезная вещь, которую вы можете сделать с peek заключается в том, чтобы выяснить, был ли обработан элемент потока, что именно соответствует документации API:

Возможно, эмпирическое правило должно состоять в том, что если вы используете заглянуть за рамки сценария «отладки», вы должны сделать это только в том случае, если вы уверены в том, что условия завершения и промежуточной фильтрации. Например:

return list.stream().map(foo->foo.getBar())
                    .peek(bar->bar.publish("HELLO"))
                    .collect(Collectors.toList());

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

Кажется более эффективным и элегантным чем что-то вроде:

List<Bar> bars = list.stream().map(foo->foo.getBar()).collect(Collectors.toList());
bars.forEach(bar->bar.publish("HELLO"));
return bars;

, и вы не завершаете повторную сборку дважды.

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

Теперь вопрос может быть: децентрализовать код, который может мутировать потоковые объекты или изменить глобальное состояние ?

Если ответ на любой из указанных выше двух вопросов да (или: в некоторых случаях да), тогда peek() определенно не только для целей отладки, простая или сложенная функция .

Для меня при выборе между forEach() и peek(), выбирает следующее: хочу ли я фрагменты кода, которые мутируют объекты потока, которые должны быть прикреплены к составному, или я хочу, чтобы они напрямую привязывались к потоку?

Я думаю, peek() будет лучше пара с методами java9. например takeWhile(), возможно, потребуется решить, когда остановить итерацию на основе уже мутировавшего объекта, поэтому его использование с forEach() не будет иметь такого же эффекта.

определенно не только для целей отладки Я нигде не ссылался на map(), потому что если мы хотим мутировать объекты (или глобальное состояние), а не генерировать новые объекты, он работает точно так же, как peek().

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

Как и в случае использования, предположим, что вы хотите отфильтровать только активные учетные записи, а затем выполнить вход в эти учетные записи.

accounts.stream()
    .filter(Account::isActive)
    .peek(login)
    .collect(Collectors.toList());

Peek помогает избежать избыточного вызова, не требуя повторной итерации коллекции:

accounts.stream()
    .filter(Account::isActive)
    .map(account -> {
        account.login();
        return account;
    })
    .collect(Collectors.toList());