Неблокирующий и асинхронный ввод-вывод Java с NIO и NIO.2 (JSR203) — реализации Reactor/Proactor

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

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

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

См. AsyncrhonousSocketChannel, AsynchronousServerSocketChannel

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

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

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

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

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

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

. . .

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

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

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

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

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

одна из моих любимых книг по шаблонам программного обеспечения (Pattern-Oriented Software Architecture — Patterns for Concurrent and Networked Objects)

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

В настоящее время я считаю, что NIO уже является фреймворком и шаблоном проектирования.

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

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