ByteBuffer.allocate () против ByteBuffer.allocateDirect ()

Кому allocate()или кому allocateDirect(), вот в чем вопрос.

В течение нескольких лет я просто придерживался мысли, что, поскольку DirectByteBuffers являются прямым отображением памяти на уровне ОС, он будет работать быстрее с вызовами get / put, чем HeapByteBuffers. До сих пор я никогда не был заинтересован в том, чтобы узнать точные детали ситуации. Я хочу знать, какой из двух типов ByteBufferработает быстрее и при каких условиях.

Рон Хитчес в своей превосходной книге Java NIO, кажется, предлагает то, что, по моему мнению, могло бы стать хорошим ответом на ваш вопрос:

Операционные системы выполняют операции ввода-вывода в областях памяти. С точки зрения операционной системы, эти области памяти представляют собой непрерывные последовательности байтов. Поэтому неудивительно, что только байтовые буферы имеют право участвовать в операциях ввода-вывода. Также помните, что операционная система будет напрямую обращаться к адресному пространству процесса, в данном случае процесса JVM, для передачи данных. Это означает, что области памяти, которые являются целями операций ввода-вывода, должны представлять собой непрерывные последовательности байтов. В JVM массив байтов не может храниться в памяти непрерывно, или сборщик мусора может переместить его в любое время. Массивы - это объекты в Java, и способ хранения данных внутри этого объекта может варьироваться от одной реализации JVM к другой.

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

Прямые байтовые буферы обычно являются лучшим выбором для операций ввода-вывода. По своей конструкции они поддерживают наиболее эффективный механизм ввода-вывода, доступный JVM. Непрямые байтовые буферы могут быть переданы в каналы, но это может привести к снижению производительности. Обычно непрямой буфер не может быть целью собственной операции ввода-вывода. Если вы передаете непрямой объект ByteBuffer в канал для записи, канал может неявно выполнять следующие действия при каждом вызове:

1. Создайте временный прямой объект ByteBuffer.
2. Скопируйте содержимое непрямого буфера во временный буфер.
3. Выполните операцию ввода-вывода низкого уровня, используя временный буфер.
4. Объект временного буфера выходит за пределы области видимости и в конечном итоге собирается сборщиком мусора.

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

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

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

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

поскольку DirectByteBuffers - это прямое отображение памяти на уровне ОС

Это не так. Это просто обычная память процесса приложения, но она не подлежит перемещению во время Java GC, что значительно упрощает работу на уровне JNI. То, что вы описываете, применимо к MappedByteBuffer.

что он будет работать быстрее с вызовами get / put

Вывод не следует из посылки; посылка ложная; и вывод тоже ложный. Они работают быстрее, как только вы попадаете внутрь уровня JNI, и если вы читаете и записываете с того же уровня, DirectByteBufferони намного быстрее, потому что данные никогда не должны пересекать границу JNI.

Лучше всего делать свои собственные измерения. Быстрый ответ, похоже, заключается в том, что отправка из allocateDirect()буфера занимает на 25-75% меньше времени, чем allocate()вариант (тестировался как копирование файла в / dev / null), в зависимости от размера, но само выделение может быть значительно медленнее (даже на в 100 раз).

Источники:

• Почему разница в кривой производительности между ByteBuffer.allocate () и ByteBuffer.allocateDirect ()

• ByteBuffer.allocateDirect смехотворно медленный

• Когда использовать массив, буфер или прямой буфер