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