JVM: Когда JVM нужно скопировать содержимое памяти

Question

Я только что прочитал вики here, один из пассажей сказал:

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

Я любопытный о словах «исключает необходимость какого-либо дополнительного копирования», когда будет JVM это нужно и почему NIO могли избежать?

Answer 1

Речь идет о прямом сопоставлении между структурой данных ядра и структурой данных пользовательского пространства; обычно при переходе между ними обычно требуется контекстный переключатель. Однако с помощью nio и прямого буфера контекстный переключатель (и соответствующие копии памяти) не возникает.

Answer 2

Из java.nio пакета API:

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

Пример:

FileChannel fc = ... 
ByteBuffer buf = ByteBuffer.allocateDirect(8192); 
int n = fc.read(buf); 

Answer 3

просто, старый IO путь всегда копировать данные из ядра памяти в куче. Использование NIO позволяет использовать буферы, в которых файл/сетевой поток напрямую отображается ядром. Результат: меньшее потребление памяти и намного лучшая производительность.

Answer 4

Многие разработчики знают только одну JVM, JVM Oracle HotSpot и говорят о сборке мусора в целом, когда речь идет конкретно о реализации Oracle HotSpot. но дело в проверке Bob's post

Answer 5

Новая библиотека ввода/вывода (NIO), представленная с помощью JDK 1.4, обеспечивает высокоскоростной блок-ориентированный ввод-вывод в стандартном Java-коде.

Несколько точек на NiO,

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

API NIO вводит новую примитивную абстракцию ввода-вывода, называемую каналом. Канал представляет собой открытое соединение с объектом, таким как аппаратное устройство, файл, сетевой сокет. Когда вы используете APIs FileChannel.transferTo() или FileChannel.transferFrom() JVM использует доступ ОС к DMA (Прямой доступ к памяти), который является потенциальным преимуществом.

В соответствии с Ron Hitches на Java NIO

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

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

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

Глава 2 на ниже учебник даст вам больше понимания (особенно 2.4, 2.4.2 и т.д.) http://blogimg.chinaunix.net/blog/upfile2/090901134800.pdf