Параллельное поведение потока Java для allMatch, noneMatch, filter и map

Question

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

Я полагаю, но подумал, что кто-то может проверить, является ли noneMatch и allMatch также работают таким образом, так что если при запуске noneMatch, один поток находит фактическое совпадение, то операция может возвращать ложь. Так что все остальные потоки периодически проверяют это так же, как описано для anyMatch? Similary, применяется ли обратное значение для allMatch?

Кроме того, я задавался вопросом, существует ли какая-либо разница при параллельном выполнении операций filter и map в отношении того, выполняются ли они по упорядоченному или неупорядоченному потоку. В упорядоченном потоке я предполагаю, что наиболее логичным преимуществом является просто то, что различные потоки могут обрабатывать каждый созданный подпоток, а затем объединить их все вместе в одном порядке. Для неупорядоченного потока, имеет ли это какие-либо преимущества для таких операций, как я изо всех сил пытаюсь думать о них?

Answer 1

Все три anyMatch, allMatch и noneMatch реализованы с использованием тех же MatchOps класса с разными флагами. Таким образом, они работают очень похожим образом. Все они имеют короткое замыкание и не упорядочены, поэтому не имеет значения, заказывается ли ваш источник потока или нет: эти операции будут выполняться одинаково быстро.

Операции, подобные map и filter, не имеют никакой пользы от неупорядоченного источника. Неупорядоченный источник изменяет алгоритм для distinct, limit, skip, takeWhile (Java-9), dropWhile (Java-9). Кажется, что нормальное сокращение (через reduce или collect) не оптимизирует неупорядоченный случай (хотя мои самые предварительные исследования показывают, что такая оптимизация будет возможна).