Java: Сохраняйте большой бинарный файл в памяти для многократного использования (byte[]? ByteBuffer??)

Я читаю бинарные файлы из InputStream и должен хранить их в памяти для дальнейшей обработки. Самый очевидный подход — хранить прочитанные данные каждого файла в массиве byte[]. Но я предполагаю, что есть более элегантные способы, которые предоставляют некоторый OO API для "файловых блоков" в памяти. Чтобы вы посоветовали?

  • Должно быть возможно многократное чтение без перестройки структуры данных (доступ для чтения не должен влиять на внутреннее состояние большого двоичного объекта).
  • (Случайный) Доступ для записи не требуется. Нет необходимости изменять определенные байты
  • Наконец, после проверки несколькими посетителями, большой двоичный объект файла, хранящийся в памяти, будет записан на диск.
  • Только чистая Java 8, никаких сторонних библиотек, таких как Apache Commons, Guava и т. д.

java file byte in-memory
person MrSnrub    schedule 22.07.2017    source источник
comment
Можете ли вы хранить весь большой двоичный объект в памяти или вам нужно реализовать какую-либо форму потоковой обработки?   -  person Florian Weimer    schedule 22.07.2017
comment
Привет, Флориан. Файлы можно хранить в памяти целиком. Размер файлов обычно не превышает нескольких МБ. Потребление памяти не является проблемой, тем более что содержимое файла мне нужно только временно.   -  person MrSnrub    schedule 22.07.2017

Ответы (1)


arrow_upward
2
arrow_downward

Если все помещается в память и данные быстро отбрасываются, используйте byte[]s или непрямые (!) java.nio.ByteBuffers (которые в любом случае являются просто обертками вокруг байтовых массивов). Преимущество байтовых буферов заключается в том, что вы можете предоставить ссылку на тот же большой двоичный объект, через который нельзя внести изменения в большой двоичный объект, используя метод asReadOnlyBuffer(). С byte[] для этого требуется защитная копия. Что касается дополнительных накладных расходов из-за ByteBuffer: компиляторы Hotspot довольно хорошо устраняют это, и ваши большие двоичные объекты кажутся довольно большими, поэтому дополнительное выделение не должно иметь значения.

person Florian Weimer    schedule 22.07.2017