Как БЫСТРО получить список каталогов в Java?

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

Если вам по какой-то причине нужно хранить все файлы в одном каталоге, я думаю, вам придется поддерживать свой собственный кеш. Это можно сделать с помощью локальной базы данных, такой как sqlite, HeidiSQL или HSQL. Если вам нужна максимальная производительность, используйте java TreeSet и кэшируйте его в памяти. Это означает, по крайней мере, что вам придется реже читать каталог, и, возможно, это можно сделать в фоновом режиме. Вы можете уменьшить потребность в обновлении списка еще больше, используя собственный API уведомлений об обновлении файлов вашей системы (inotify в Linux), чтобы подписаться на изменения в каталоге.

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

images/[id - (id % 1000000)]/[id - (id % 1000)]/[id].jpg

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

Знаете ли вы конечный список возможных имен подкаталогов? Если это так, используйте цикл по всем возможным именам и проверьте существование каталога.

В противном случае вы не сможете получить ТОЛЬКО имена каталогов в большинстве базовых ОС (например, в Unix список каталогов просто читает содержимое файла «каталога», поэтому нет возможности быстро найти «только каталоги», не перечисляя все файлы).

Однако в NIO.2 в Java7 (см. http://java.sun.com/developer/technicalArticles/javase/nio/#3 ), есть способ иметь список каталогов потоковой передачи, чтобы вы не получали полный массив файловых элементов, загромождающих вашу память/сеть.

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

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

Второе: каталоги не хранятся в каком-либо внутреннем порядке (по крайней мере, не в тех файловых системах, где я работал с файлами каталогов). Если у вас есть 150 000 записей и 2 подкаталога, эти 2 ссылки на подкаталоги могут быть где угодно в пределах 150 000. Вы должны повторить, чтобы найти их, нет никакого способа обойти это.

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

Альтернативой является создание многоуровневой структуры каталогов. Если вы посмотрите на коммерческие веб-сайты, вы увидите такие URL-адреса, как /1/150/15023.html — это предназначено для уменьшения количества файлов в каталоге. Думайте об этом как об индексе BTree в базе данных.

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

Ключевой проблемой может быть функция File.isDirectory(), вызываемая в цикле.

File.isDirectory() может быть очень медленным. Я видел, как NFS требуется 10 секунд для обработки каталога с 200 файлами.

Если вы можете во что бы то ни стало предотвратить вызовы File.isDirectory() (например, проверить наличие расширения, каталог без расширения ==), вы можете значительно улучшить производительность.

В противном случае я бы предложил сделать JNA/JNI/написать собственный скрипт, который сделает это за вас.

Библиотека jCifs позволяет более эффективно управлять общими сетевыми ресурсами Windows. Я не знаю библиотеки, которая сделала бы это для других сетевых файловых систем.

Я столкнулся с подобным вопросом при отладке производительности в приложении Java, перечисляющем множество файлов. Он использует старый подход

for (File f : new File("C:\\").listFiles()) {
    if (f.isDirectory()) {
        continue;
    }        
}

И кажется, что каждый f.isDirectory() является вызовом собственной FileSsystem, которая, по крайней мере, в NTFS, очень медленная. Java7 NIO имеет дополнительный API, но там не все методы хороши. Я просто приведу результаты теста JMH здесь

Benchmark                  Mode  Cnt  Score    Error  Units
MyBenchmark.dir_listFiles  avgt    5  0.437 ?  0.064   s/op
MyBenchmark.path_find      avgt    5  0.046 ?  0.001   s/op
MyBenchmark.path_walkTree  avgt    5  1.702 ?  0.047   s/op

Число исходит от выполнения этого кода:

java -jar target/benchmarks.jar -bm avgt -f 1 -wi 5 -i 5 -t 1

static final String testDir = "C:/Sdk/Ide/NetBeans/src/dev/src/";
static final int nCycles = 50;

public static class Counter {
    int countOfFiles;
    int countOfFolders;
}

@Benchmark
public List<File> dir_listFiles() {
    List<File> files = new ArrayList<>(1000);

    for( int i = 0; i < nCycles; i++ ) {
        File dir = new File(testDir);

        files.clear();
        for (File f : dir.listFiles()) {
            if (f.isDirectory()) {
                continue;
            }
            files.add(f);
        }
    }
    return files;
}

@Benchmark
public List<Path> path_walkTree() throws Exception {
    final List<Path> files = new ArrayList<>(1000);

    for( int i = 0; i < nCycles; i++ ) {
        Path dir = Paths.get(testDir);

        files.clear();
        Files.walkFileTree(dir, new SimpleFileVisitor<Path> () {
            @Override
            public FileVisitResult visitFile(Path path, BasicFileAttributes arg1) throws IOException {
                files.add(path);
                return FileVisitResult.CONTINUE;
            }

            @Override
            public FileVisitResult preVisitDirectory(Path path, BasicFileAttributes arg1) 
                    throws IOException {
                return path == dir ? FileVisitResult.CONTINUE : FileVisitResult.SKIP_SUBTREE;
            }
        });
    }

    return files;
}

@Benchmark
public List<Path> path_find() throws Exception {
    final List<Path> files = new ArrayList<>(1000);

    for( int i = 0; i < nCycles; i++ ) {
        Path dir = Paths.get(testDir);

        files.clear();
        files.addAll(Files.find(dir, 1, (path, attrs) 
                -> true /*!attrs.isDirectory()*/).collect(Collectors.toList()));
    }

    return files;
}

Вы могли бы взломать его, если бы все 150 000 файлов (или значительное их количество) имели аналогичное соглашение об именах, например:

*.jpg
*Out.txt

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

Я не знаю, съедят ли его накладные расходы на cmd.exe, но один из вариантов может быть примерно таким:

...
Runtime r = Runtime.getRuntime();
Process p = r.exec("cmd.exe /k dir /s/b/ad C:\\folder");
BufferedReader br = new BufferedReader(new InputStreamReader(p.getInputStream()));
for (;;) {
    String d = br.readLine();
    if (d == null)
        break;
    System.out.println(d);
}
...

• /s означает поиск в подкаталогах
• /ad означает, что возвращаются только каталоги
• /b означает возврат полного пути от корня

если ваша ОС «стабильна», попробуйте JNA:

• opendir/readdir в UNIX
• FindFirstFile и соответствующий API в Windows
• Java7 с NIO2

все это «потоковое API». Они не заставляют вас выделять список/массив 150k перед началом поиска. ИМХО это большое преимущество в вашем сценарии.

Вот нестандартное решение, вообще лишенное каких-либо испытаний. Это также зависит от наличия файловой системы, поддерживающей символические ссылки. Это не решение для Java. Я подозреваю, что ваша проблема связана с файловой системой/ОС, а не с Java.

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

/symlinks/a/b/cde

будет ссылаться на

/realfiles/abcde

(где /realfiles — это место, где находятся ваши 150 000 файлов)

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

также существует рекурсивное параллельное сканирование по адресу http://blogs.oracle.com/adventures/entry/fast_directory_scanning. По существу братья и сестры обрабатываются параллельно. Есть и обнадеживающие тесты производительности.

Возможно, вы могли бы написать программу поиска в каталогах на C#/C/C++ и использовать JNI, чтобы перевести ее на Java. Не знаю, улучшит ли это производительность или нет.

Ну, либо JNI, либо, если вы говорите, что ваше развертывание является постоянным, просто запустите «dir» в Windows или «ls» в * nixes с соответствующими флагами для вывода списка только каталогов (Runtime.exec())

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

Редактировать: Идея: один из вариантов — скрыть от глаз пользователя медлительность листинга каталога. В клиентском приложении вы можете использовать некоторую анимацию, пока листинг работает, чтобы отвлечь пользователя. На самом деле зависит от того, что еще делает ваше приложение помимо листинга.

По состоянию на 2020 год DirectoryStream кажется быстрее, чем использование File.listFiles() и проверка каждого файла с помощью isDirectory().

Я узнал ответ отсюда:

https://www.baeldung.com/java-list-directory-files

Я использую Java 1.8 в Windows 10.