Преимущества Java NIO в режиме блокировки по сравнению с традиционным вводом / выводом?

Question

Я уже почти решил не использовать асинхронную неблокирующую Java NIO.Сложность в сравнении с преимуществами в целом очень сомнительна, и я думаю, что в этом проекте это особенно не стоит.

Но большая часть того, что я читал о NIO и сравнениях с более ранним java.io. *, фокусируется наблокирование, асинхронный NIO по сравнению с синхронным вводом / выводом потокового соединения с использованием java.io. *.Тем не менее, NIO можно использовать в синхронном, блокирующем режиме с потоком на соединение, который, как кажется, редко обсуждается.

Вот вопрос: есть ли какое-либо преимущество в производительности синхронного блокирования NIO по сравнению с традиционным синхронным блокированием?I / O (java.io. *)?Оба будут поток-на-соединение.Какова сложность сравнения?

Обратите внимание, что это общий вопрос, но в данный момент я в основном касаюсь связи через сокет TCP.

Answer 1

Преимущество NIO перед «традиционным» IO заключается в том, что NIO может использовать прямые буферы , которые позволяют ОС использовать DMA для некоторых операций (например, чтение из сетевого подключения непосредственно в отображенный в память файл) и, таким образом, избегайте копирования данных в промежуточные буферы.

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

Answer 2

Это в основном сводит количество одновременных подключений и их загруженность.Блокировка (стандартный поток на соединение) быстрее, как по задержке, так и по пропускной способности (примерно в два раза быстрее для простого эхо-сервера).Поэтому, если ваша система может справиться с поддержкой потока для каждого соединения (<1000 подключений, как правило), используйте блокирующий подход.Если у вас много в основном незанятых соединений (например, длинные запросы на опрос Comet или незадействованные соединения IMAP), то переход на неблокирующую архитектуру может помочь масштабировать вашу систему. </p>

Answer 3

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

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