как выбрать java nio против io?

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

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

Распространенным вариантом является использование неблокирующего NIO с селекторами. Большая часть сложности, которую это вносит, может быть решена такими фреймворками, как Netty или Mina. Я предлагаю вам использовать такую ​​библиотеку, если вам нужен неблокирующий ввод-вывод, например. потому что у вас есть тысячи одновременных подключений к серверу. ИМХО У вас тысячи подключений, вам следует подумать о том, чтобы иметь больше серверов, если только то, что делает каждое подключение, не является довольно тривиальным. Насколько я знаю, Google использует больше серверов, а не тысячи пользователей на сервер.

Более экстремальный вариант — использовать NIO2. Это еще более сложно и долго писать, чем неблокирующий NIO. Я не знаю никаких фреймворков, которые хорошо это поддерживают. то есть это на самом деле быстрее, когда вы это делаете. AFAIK Похоже, это стоит использовать, если у вас есть Infiniband (для чего он и был разработан), но, возможно, не стоит использовать, если у вас есть Ethernet.

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

Немного поздно, но лично я использую NIO даже для обычной «повседневной» обработки файлов. Итак, я использую такие вещи, как:

 1. if(Files.notExists(path)) { } 
 2. Files.createDirectory(path);
 3. Files.newInputStream(path) targetPath.resolve("somefile.txt");
 4. Files.newBufferedWriter(path, charset);
 5. DirectoryStream<Path> directoryStream = Files.newDirectoryStream(path);

и он отлично работает для меня. Я предпочитаю Path вместо старого File из-за таких методов, как relativize или resolveSibling.

Не кажется мне более сложным, чем IO.

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

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

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

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

Некоторые преимущества API NIO.2 по сравнению с устаревшим классом java.io.File для работы с файлами:

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

Конкретные варианты использования и дополнительные сведения см. в этом статья

Традиционный ввод-вывод — это простой и упрощенный код, NIO — более сложный, но и более гибкий. В моем случае я предпочитаю использовать IO для маленьких потоков и NIO для больших потоков, но nio действительно сложнее

с NIO мне нужно создать целый пакет для управления им вместо пакета io, который я напрямую использую snippet