как да избера java nio срещу io?

IMHO, Блокирането на IO обикновено е най-простият за използване и освен ако нямате конкретно изискване, което изисква повече от вашата система, трябва да се придържате към най-простата опция.

Следващата най-проста опция е блокиране на NIO, което често предпочитам, ако искам нещо повече ефективност или контрол от IO. Все още е относително прост, но ви позволява да използвате ByteBuffers. напр. ByteBuffers поддържат little endian.

Обичайна опция е да се използва неблокиращ NIO със селектори. Голяма част от сложността, която това въвежда, може да се справи с рамки като Netty или Mina. Предлагам ви да използвате такава библиотека, ако имате нужда от неблокиращ IO, напр. защото имате хиляди едновременни връзки на сървър. IMHO Имате хиляди връзки, трябва да помислите за повече сървъри, освен ако това, което прави всяка връзка, е доста тривиално. AFAIK Google търси повече сървъри, а хиляди потребители на сървър.

По-екстремният вариант е използването на NIO2. Това е още по-сложно и продължително записване от неблокиращ NIO. Не знам за никакви рамки, които поддържат това добре. т.е. всъщност е по-бързо, когато го направите. AFAIK Изглежда, че това си струва да се използва, ако имате Infiniband (което е предназначено да поддържа), но може би не си струва да се използва, ако имате Ethernet.

Ако искате неблокиращ IO, NIO не е по-добрият избор, той е единственият избор в Java. Имайте предвид, че хората все още използват стария IO редовно, защото е много по-лесно да се кодира срещу него. NIO API е доста суров и е по-скоро позволяваща технология на ниско ниво, отколкото API от страна на клиента. Предлагам да използвате NIO чрез API, който предоставя по-прост интерфейс за проблемите, които искате да разрешите, като използвате неблокиращ IO.

Малко късно, но лично аз използвам 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, тъй като това е нов и модерен начин за писане на мултиклиентски сървъри за задачи с висока пропускателна способност.

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

• Поддържа зависещи от файловата система атрибути.
• Позволява ви да обхождате директно дърво на директория.
• Поддържа символни връзки.

За конкретни случаи на употреба и повече подробности можете да видите това статия

Традиционният IO е лесен и опростен код, NIO е по-сложен, но по-гъвкав. В моя случай предпочитам да използвам IO за малък стрийминг и NIO за голям стрийминг, но nio наистина е по-сложен

с NIO трябва да създам цял пакет, за да го управлявам вместо io пакет, който директно използвам snippet