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

Запустил ваш код на 1 папке - Jenkins (66108 файлов). С ходу получил NPE на рекурсии exetuteFolder. А JMH вообще вешается от OutOfMemory уже на 6й итерации.

К слову, запустил бенч на выше приведенном Java 8 коде. Результаты последовательного запуска метода подсчета общего числа файлов в списке из 2х крупных каталогов (133458 файлов).

А теперь с включенным parallelStream() по фолдерам:

Включенный parallel() для файлов:

Включены оба parallelStream() и parallel():

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

А теперь давайте посмотрим на результаты для 9 маленьких файлов в 3х каталогах.

Последовательная обработка:

Параллелизация по файлам:

По каталогам:

Обе опции:

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

Вывод 1: всегда делайте замеры перед использованием параллелизации.
Вывод 2: используйте опцию параллелизации аккуратно, ибо даже на маленьких выборках вы можете и вовсе потерять в производительности.

4 лайка

Походу моя “программа” - вообще отстой!

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