Java 7 параллельный поиск файлов рекурсивно в папке

Question

Я хотел бы использовать API-интерфейс Visitor в Java 7 для поиска рекурсивно файлов в папке. Поскольку я буду искать большие папки, с более чем 100 000 файлами, разделенными через папки, я хотел бы сделать это параллельно.

Но я не могу, например, создать нить для каждой папки. May Fork Join может быть идеей, но из того, что я понял, FJ обычно используется, когда вы знаете данные, например, у вас есть данный массив, и вы хотите обрабатывать части из 5 элементов. Таким образом, деление и победа могут быть использованы очень хорошо в этом случае.

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

Спасибо, Рю

Answer 1

Вы не можете использовать Files.walkFileTree для этого (я предполагаю, что это то, что вы имеете в виду, когда говорите «API посетителя, в Java 7»); вы должны сами реализовать обход каталога, чтобы иметь возможность распараллеливать его.

Вилка/присоединение., Фактически, подходит эта проблема очень хорошо. Существует даже соответствующий пример на Fork and Join: Java Can Excel at Painless Parallel Programming Too!. В этой статье есть пример программы, в которой «подсчет [s] вхождения слова в набор документов» путем перемещения файлов в каталоге и всех его подкаталогов (рекурсивно).

Автор предлагает некоторые, казалось бы, положительные оценки ускорения в разделе обсуждения, но вы должны подумать о том, что Дариуш сказал о проблеме, возможно, связанной с привязкой к IO, а не о привязке к ЦП (т. Е. Простое бросание большого количества потоков на нем не приведет к каким-либо ускорение после некоторого, возможно, низкого количества потоков). Удивительно, по крайней мере, для меня, что примерная программа из статьи была быстрее с 12 потоками, чем с 8 потоками.

Отмена, afaics, является ортогональной проблемой для этого и может быть реализована стандартным способом (например, опрос volatile).

Answer 2

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

Вы действительно написали код? Вы проверили это? Вы прокомментировали это? Что вы вычитали из профилирования?

Помните, что первое правило оптимизации: don't do it.