Это не LINQ2SQL.
кроме того, LINQ не используется для обновления, только для запросов для объектов.
Мне кажется, что вы собираетесь иметь для загрузки файла в память, если хотите избежать конфликтов ввода-вывода. Операционная система выполнит некоторую буферизацию, но если вы обнаружите, что этого недостаточно, вам придется сделать это самостоятельно.
Вам действительно нужно 32 потока? Предположительно у вас не так много ядер, поэтому используйте меньше потоков, и вы получите меньше переключения контекста и т. Д.
Все ли ваши потоки обрабатывают файл от начала до конца? Если да, могли бы вы эффективно разбить файл на куски? Прочтите первые (скажем) 10 МБ данных в память, позвольте всем потокам обработать их, затем перейдите к следующим 10 МБ и т. Д.
Если это не сработает для вас, сколько памяти у вас есть по сравнению с размером файла? Если у вас много памяти, но у вас ее нет Если вы хотите выделить один огромный массив, вы можете прочитать весь файл в памяти, но на множество отдельных небольших массивов байтов. Затем вам нужно будет написать входной поток, охватывающий все эти массивы байтов, но это должно быть выполнимо.
Несколько идей:
Напишите собственную реализацию InputStream, которая действует как представление для FileChannel. Напишите это так, чтобы оно не зависело ни от какого состояния в FileChannel. (то есть: каждый экземпляр должен отслеживать свою позицию, а чтение должно использовать абсолютные чтения в базовом FileChannel.) Это, по крайней мере, поможет вам решить проблемы, которые у вас были с Channels.newInputStream (), но это может не решить ваши проблемы с конфликтом ввода-вывода .
Напишите собственную реализацию InputStream, которая действует как представление для MappedByteBuffer. Отображение памяти не должно быть таким плохим, как на самом деле считывание всего этого в память сразу, но вы все равно съедите 1 ГБ виртуального адресного пространства.
То же, что и № 1, но имеет какой-то общий слой кэширования. Я бы не стал пробовать это, если 1 не окажется достаточно эффективным, а 2 - невозможным. На самом деле, ОС уже должна выполнять кеширование для вас в №1, так что здесь вы, по сути, пытаетесь быть умнее, чем кэширование файловой системы ОС.
Это очень большой файл. Можно ли получить файл в виде меньшего набора файлов? Простая доставка этого файла будет большой работой даже в корпоративной сети.
Иногда проще изменить процесс, чем программу.
Возможно, вам даже лучше написать что-нибудь, чтобы разбить файл на несколько частей. и обрабатывать их отдельно.
вы можете открывать файл несколько раз в режиме только для чтения. Вы можете получить доступ к файлу любым способом. Просто оставьте кеширование ОС. Когда он слишком медленный, вы можете рассмотреть вариант кэширования на основе фрагментов, при котором все потоки могут обращаться к одному и тому же кешу.