Многопоточность Java, читая единственный большой файл

Это не LINQ2SQL.

кроме того, LINQ не используется для обновления, только для запросов для объектов.

7
задан bob 10 October 2009 в 06:28
поделиться

4 ответа

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

Вам действительно нужно 32 потока? Предположительно у вас не так много ядер, поэтому используйте меньше потоков, и вы получите меньше переключения контекста и т. Д.

Все ли ваши потоки обрабатывают файл от начала до конца? Если да, могли бы вы эффективно разбить файл на куски? Прочтите первые (скажем) 10 МБ данных в память, позвольте всем потокам обработать их, затем перейдите к следующим 10 МБ и т. Д.

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

10
ответ дан 6 December 2019 в 12:52
поделиться

Несколько идей:

  1. Напишите собственную реализацию InputStream, которая действует как представление для FileChannel. Напишите это так, чтобы оно не зависело ни от какого состояния в FileChannel. (то есть: каждый экземпляр должен отслеживать свою позицию, а чтение должно использовать абсолютные чтения в базовом FileChannel.) Это, по крайней мере, поможет вам решить проблемы, которые у вас были с Channels.newInputStream (), но это может не решить ваши проблемы с конфликтом ввода-вывода .

  2. Напишите собственную реализацию InputStream, которая действует как представление для MappedByteBuffer. Отображение памяти не должно быть таким плохим, как на самом деле считывание всего этого в память сразу, но вы все равно съедите 1 ГБ виртуального адресного пространства.

  3. То же, что и № 1, но имеет какой-то общий слой кэширования. Я бы не стал пробовать это, если 1 не окажется достаточно эффективным, а 2 - невозможным. На самом деле, ОС уже должна выполнять кеширование для вас в №1, так что здесь вы, по сути, пытаетесь быть умнее, чем кэширование файловой системы ОС.

1
ответ дан 6 December 2019 в 12:52
поделиться

Это очень большой файл. Можно ли получить файл в виде меньшего набора файлов? Простая доставка этого файла будет большой работой даже в корпоративной сети.

Иногда проще изменить процесс, чем программу.

Возможно, вам даже лучше написать что-нибудь, чтобы разбить файл на несколько частей. и обрабатывать их отдельно.

0
ответ дан 6 December 2019 в 12:52
поделиться

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

5
ответ дан 6 December 2019 в 12:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: