Неблокируемый Java и асинхронный ввод-вывод с NIO & NIO.2 (JSR203) - Реактор / Реактор Реализации

Question

Итак, я читаю одну из моих любимых программных таблиц шаблонов (Шаблонно-ориентированная архитектура программного обеспечения - Шаблоны для параллельных и сетевых объектов), в частности разделы по шаблонам асинхронного ввода-вывода Proactor / Reactor.Я вижу, как с помощью выбираемых каналов я могу довольно легко реализовать механизм асинхронного ввода-вывода в стиле Reactor (и сделал это).Но я не понимаю, как бы я реализовал правильный механизм Proactor с неблокирующими записями.Это использование управляемых ОС неблокирующих функций записи.

Функциональность, поддерживаемая вызовами, специфичными для ОС, такими как GetQueuedCompletionStatus под win32.

Я видел, что Java 7 приносит некоторые обновления в NIO с обработчиками асинхронного завершения (что, кажется, в правильном направлении).При этом ... Учитывая отсутствие единой межплатформенной поддержки асинхронных операций, управляемых ОС (в частности, асинхронной записи), я предполагаю, что это квасная реализация, не использующая встроенную поддержку ОС.

Итакмои вопросы: возможна ли обработка Java на основе Proactor в Java таким образом, что ее выгодно использовать для конкретных сценариев;и если Java NIO поддерживает обработку ввода-вывода на основе proactor (либо в Java 6, либо в Java 7), то используется ли управляемая ОС поддержка асинхронного ввода-вывода (то есть обратные вызовы завершения из ОС)?Кроме того, если реализация исключительно в VM, преимущества в производительности настолько малы, что использование упреждающей обработки событий предлагает не что иное, как другой (возможно, более простой) способ создания программного обеспечения для одновременной обработки сети.

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

Answer 1

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

Возможна ли обработка ввода-вывода на основе процессора в Java таким образом, что это выгодно использовать для конкретных сценарии.

В Java 1.4 введен неблокирующий ввод-вывод, который НЕ совпадает с асинхронным вводом-выводом. В Java SE 7 введен асинхронный ввод-вывод с JSR203, что делает возможными «настоящие» реализации обработки ввода-вывода в стиле проактора.

См. AsyncrhonousSocketChannel , AsynchronousServerSocketChannel

и, если Java NIO поддерживает proactor обработка ввода-вывода на основе (либо в Java 6, либо Java 7) это ОС, управляемая асинхронным вводом-выводом поддержка (т.е. обратные вызовы завершения из ОС) используется?

При чтении спецификаций JSR 203 обработчики завершения, использующие новые асинхронные каналы, безусловно, поддерживаются, и сообщается, что используются встроенные функции ОС, но я еще не выяснил, в какой степени. Я могу последовать этому после анализа источника Java 7 (если кто-то не превзойдет меня).

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

Мне не удалось найти никаких сравнений производительности в отношении новых функций асинхронного ввода-вывода в Java 7. Я уверен, что они станут доступны в ближайшем будущем.

Как всегда, когда предоставляется более одного способа решения проблемы, на вопросы о том, какой подход лучше, почти всегда отвечает «зависит». Упреждающая обработка событий (с использованием обработчиков асинхронного завершения) включена в Java 7 и не может просто существовать без цели. Для определенных приложений будет иметь смысл использовать такую ​​обработку ввода-вывода. Исторически распространенным примером, когда proactor имеет хорошую применимость, является HTTP-сервер, где часто выдается много коротких запросов. Для более глубокого объяснения прочитайте это (предоставляется только для того, чтобы подчеркнуть преимущества proactor, поэтому постарайтесь не учитывать тот факт, что пример кода - C ++).

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

. , .

С другой стороны, я настоятельно рекомендую прочитать следующую презентацию о NIO , которая предлагает сравнение производительности между NIO и "традиционным" подходом. Хотя я бы также посоветовал с осторожностью относиться к результатам, представленным, поскольку реализация NIO в тесте производительности была основана на библиотеке NIBIO NIO до Java 1.4, а не на реализации NIO, поставляемой в версии 1.4.

Answer 2

Я бы хотел проверить, действительно ли вам нужно беспокоиться о блокировке записей.

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

Если вы хотите неблокирующий ввод-вывод, сделайте это для чтения и, следовательно, для записи.

Примечание: Использование блокирования ввода-вывода с NIO обычно проще и может не выполнять неблокирующую NIO, если у вас нет 1000 соединений, вы, вероятно, обнаружите, что добавленная сложность того не стоит. (И, возможно, не самый лучший вариант)

Answer 3

одна из моих любимых книг по программным образцам (Архитектура программного обеспечения на основе шаблонов - Шаблоны для параллельных и сетевых объектов)

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

Мое нынешнее мнение состоит в том, что NIO уже является структурой и шаблоном проектирования.

Answer 4

NIO уже обеспечивает реализацию реактивного шаблона (селекторы), а NIO2 добавляет реализацию активного шаблона (обработчики завершения).

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