Ввод-вывод в Java: IO и NIO на практике

Оглавление

1. Введение
2. Основные отличия между классическим IO и NIO
   • Потоково-ориентированная и буферно-ориентированная модель
   • Блокирующий и неблокирующий ввод-вывода
   • Каналы и селекторы
3. Чтение и запись файлов с помощью Java IO (пример)
4. Чтение и запись файлов с помощью Java NIO (пример)
5. Ограничения и производительность IO и NIO (и особенности Linux)
6. Сравнение Java NIO.2 (java.nio.file) и Apache Commons IO
7. Когда выбирать IO, а когда NIO?
8. Заключение

Введение

Java предоставляет мощный функционал для операций ввода-вывода (I/O – Input/Output). Исторически основной механизм I/O был реализован в пакете java.io (классическом Java IO), основанном на потоках (streams). Однако с выходом Java 1.4 (J2SE 1.4, 2002 год) появился Java NIO (New I/O) – новый подход к вводу-выводу, призванный повысить производительность и обеспечить масштабируемость систем ввода-вывода. В дальнейшем Java 7 (J2SE 1.7, 2011 год) дополнила NIO расширениями, известными как NIO.2 (новый файловый API java.nio.file.*). Цель появления NIO – устранить ограничения классического IO и предоставить разработчикам более быстрые и гибкие средства работы с файлами, сетями и прочими ресурсами. В основе NIO лежат идеи неблокирующего ввода-вывода и более прямого взаимодействия с возможностями операционной системы для достижения высокой пропускной способности.

Зачем нужны Java IO и NIO? Традиционный Java IO (пакет java.io) существует с первых версий Java и обеспечивает базовые операции чтения/записи данных (файлы, сетевые соединения, потоки данных) с упором на простоту и удобство. Java NIO был добавлен позднее, чтобы решить проблемы масштабируемости и производительности: он позволил эффективно обслуживать большое число соединений (например, в серверных приложениях) одним потоком благодаря неблокирующему вводу-выводу, а также ввел новые абстракции (буферы, каналы, селекторы), более тесно соответствующие низкоуровневым возможностям ОС. В этой статье мы подробно рассмотрим оба подхода – классический IO и современный NIO – их архитектуру, отличия, примеры использования и производительность. Начнем с ключевых концепций и различий.

Backend-разработчику важно понимать различия между Java IO и NIO, чтобы правильно выбирать инструменты под конкретные задачи: IO для простых сценариев с небольшим объемом данных и NIO для высоконагруженных, масштабируемых и асинхронных систем. Это знание помогает создавать эффективные, надежные и оптимизированные приложения, избегая проблем производительности и избыточного расхода ресурсов.

Основные отличия между классическим IO и NIO

Java IO и Java NIO решают одни и те же задачи (ввод-вывод данных), но делают это по-разному. Главные различия заключаются в следующем:

• Модель данных: потоковая vs буферная – Классический IO основан на потоках (streams), тогда как NIO оперирует буферами (buffers).
• Модель блокировки: блокирующий vs неблокирующий – Методы read()/write() в IO по умолчанию блокируют текущий поток, а NIO предоставляет режим неблокирующего ввода-вывода.
• Абстракции: Streams vs Channels/Selectors – В IO основная абстракция – потоки (InputStream, OutputStream и др.). В NIO введены каналы (Channel) и селекторы (Selector), позволяющие одним потоком обслуживать несколько каналов ввода-вывода.
• Дизайн кода и многопоточность – Приложения на IO обычно используют больше потоков (например, по одному потоку на подключение или задачу), тогда как NIO позволяет обслуживать множество подключений одним потоком, что влияет на архитектуру приложения.

Рассмотрим эти отличия подробнее.

Потоково-ориентированная и буферно-ориентированная модель

Java IO (потоковая модель): Данные читаются из источника или записываются в приемник последовательно, поток байтов за потоком. Например, InputStream позволяет читать данные побайтово или блоками байтов, продвигаясь вперед по потоку. При этом сами данные нигде не сохраняются автоматически – программист читает байты и решает, что с ними делать (можно сразу обработать или сохранить во временный буфер вручную). Невозможно произвольно перемещаться взад-вперед по потоку, не храня данные: если нужно перечитать уже пройденные байты, их следует сохранить (буферизовать) самостоятельно. Проще говоря, классический IO представляет собой однонаправленный поток данных от источника к программе (при чтении) или от программы к приемнику (при записи).

Java NIO (буферная модель): Данные читаются не напрямую программистом, а сначала помещаются в буфер – объект типа Buffer (чаще всего используют ByteBuffer для байтов). Приложение читает или пишет непосредственно в буфер. Такой подход дает большую гибкость: можно перемещаться по содержимому буфера вперед и назад, читать данные не сразу целиком, а по мере готовности и т.д.. Однако возникает задача управления буфером – нужно следить, чтобы буфер содержал все необходимые для обработки данные (если нет – дозагрузить), чтобы не перезаписать непрочитанные данные при новом чтении в буфер, переворачивать буфер из режима записи в режим чтения и пр. Буферно-ориентированный подход делает ввод-вывод двунаправленным: буфер служит посредником, через который данные могут как читаться из источника, так и записываться в приемник. В терминах NIO, взаимодействие идет через канал: программа сначала запрашивает у канала чтение данных в буфер, после чего может обработать данные из буфера; аналогично для записи – приложение кладет данные в буфер и передает буфер каналу для вывода.

Рис. 1: схематичное сравнение потокового и буферного ввода-вывода.

Слева: классический IO – данные поступают из файла через InputStream прямо в программу (поток данных идет в одном направлении). Справа: NIO – данные из файла читаются через FileChannel в промежуточный ByteBuffer, из которого программа считывает их для обработки. Буферно-ориентированная модель позволяет перемещаться по данным и использовать память более гибко.

Таким образом, классический IO можно представить как трубопровод: вы открываете поток (InputStream/OutputStream) и по нему “течет” некий непрерывный поток байтов. NIO же работает через контейнер данных (буфер): канал наполняет буфер или опустошает его, а программа может оперировать содержимым буфера (в том числе случайным доступом по индексу).

Практическое следствие: в IO вы, как разработчик, скорее оперируете потоками данных, читая их последовательно, а в NIO – оперируете буферами (блоками данных) и должны вручную управлять позицией, границами буфера (position, limit) и вызывать методы вроде flip() (переключение буфера из режима записи в режим чтения) и clear()/compact() (подготовка буфера для нового чтения) при работе. Это добавляет сложности, но открывает возможности для оптимизаций (например, повторно использовать буфер, случайно достучаться к данным и т.д.).

Рис. 2: сравнение потоковой (IO) и буферной (NIO) модели ввода-вывода

Блокирующий и неблокирующий ввод-вывода

IO – блокирующий: В традиционном Java IO вызовы чтения/записи блокируют поток выполнения до тех пор, пока данные не будут прочитаны или полностью записаны. Например, вызов InputStream.read() при отсутствии доступных данных приостановит выполнение текущего потока, пока не придут данные (или пока поток не будет закрыт). Аналогично, OutputStream.write() может блокироваться, если приемник (например, сетевой сокет) временно не готов принять данные – метод вернется только когда данные будут отправлены. Блокирующий (synchrоnous) ввод-вывод упрощает модель программирования (последовательный код, не нужно вручную опрашивать состояние ресурса), но может быть неэффективен в контексте множества задач: пока поток заблокирован на I/O операции, он не выполняет никакой другой работы. Для однозадачных сценариев или небольшого числа параллельных операций это обычно не проблема, но в серверных приложениях с тысячами соединений запускать тысячи потоков – накладно (хоть и возможно).

NIO – неблокирующий: Главное новшество Java NIO – возможность выполнять I/O операции в неблокирующем режиме. В неблокирующем режиме методы чтения/записи возвращают управление сразу, не приостанавливая поток. Если данных для чтения нет – метод вернет специальное значение (например, 0 или -1) вместо того, чтобы ждать, и поток сможет выполнить другую работу. При записи неблокирующий канал передает столько данных, сколько сможет, не дожидаясь, когда вся порция будет отправлена. Идея в том, что один поток может переключаться между множеством каналов, выполняя по чуть-чуть работы с каждым, вместо того чтобы стоять на месте, ожидая один ресурс. Неблокирующий режим особенно полезен в сочетании с сетевыми соединениями – где данные приходят непредсказуемо и ожидание на каждом сокете неэффективно.

Важно отметить, что неблокирующий режим в NIO поддерживается не для всех видов каналов. Например, файловые каналы (FileChannel) всегда работают синхронно (блокирующе) – чтение из файла с диска вызывает системный вызов и поток будет ждать его завершения. Неблокирующий ввод-вывод имеет смысл главным образом для сетевых каналов (например, SocketChannel), где данные могут поступать или отправляться асинхронно. Для файлов Java 7+ предлагает другой подход – асинхронный канал AsynchronousFileChannel, который использует фоновые потоки или возможности ОС для асинхронного ввода-вывода. Но обычный FileChannel работает синхронно (несмотря на использование буферов и каналов, вызов read/write на файле блокируется до выполнения). Таким образом, применительно к файлам выигрыш NIO над IO заключается не в неблокирующем чтении (его нет для файлов), а в других аспектах – например, в эффективности работы с большими объемами данных (zero-copy, memory-mapped I/O и пр., о чем ниже).

Для сетевых же коммуникаций NIO открывает возможность писать высокопроизводительные серверы: вместо того, чтобы иметь по одному потоку на каждого клиента (как было бы в блокирующей модели с ServerSocket + Socket), можно иметь один поток, обрабатывающий сотни или тысячи сокетов в неблокирующем режиме. Это существенно снижает накладные расходы на контекстные переключения, сокращает потребление памяти (не нужно тысячи стеков потоков) и упрощает синхронизацию. Ниже мы рассмотрим, как это достигается с помощью селекторов.

Каналы и селекторы

Каналы (Channels): В NIO введена новая абстракция – интерфейс java.nio.channels.Channel и его реализации (например, FileChannel, SocketChannel, DatagramChannel и т.д.). Канал можно представить как двунаправленный канал связи для передачи данных между источником/приемником данных и буфером. Например, FileChannel соединяет файл с буфером, SocketChannel – сетевой сокет с буфером. В отличие от потоков (InputStream/OutputStream), каналы могут быть двунаправленными (некоторые каналы поддерживают как чтение, так и запись через один и тот же объект). Также каналы более низкоуровневые: они могут поддерживать такие операции, как работа с позицией (например, FileChannel.position() позволяет узнавать/устанавливать текущую позицию в файле для чтения/записи) и параллельный доступ (один канал можно использовать из нескольких потоков, хотя нужно быть осторожным с синхронизацией позиций). Канал обеспечивает эффективную передачу данных – часто напрямую через системные вызовы, минуя лишние обертки. Например, канал может использовать операцию типа read() ОС, которая читает сразу блок в память, или даже специальные возможности вроде DMA и zero-copy (подробнее в разделе о производительности). В общем, канал – это шлюз к ресурсу, через который мы можем читать/писать с помощью буферов. Без буфера канал не очень полезен – практически все операции канала принимают или возвращают объекты Buffer.

Селекторы (Selectors): Селектор – еще одна ключевая часть NIO, отвечающая за неблокирующее управление множеством каналов. Объект java.nio.channels.Selector позволяет зарегистрировать несколько каналов (например, множество сокетов) и затем одним методом select() отслеживать, на каких из них появились данные для чтения, либо готовность для записи и т.д.. Работа с селектором обычно выглядит так:

1. Перевести каналы (например, SocketChannel) в неблокирующий режим (configureBlocking(false)),
2. Зарегистрировать каждый канал в селекторе на интересующие события (чтение, запись, подключение и т.п.),
3. В цикле вызывать selector.select() – этот вызов блокируется, но не на конкретном сокете, а сразу на всех зарегистрированных каналах. Как только любой из каналов станет готов (например, пришли данные на один из сокетов), select() возвращает управление, и можно получить список “готовых” каналов. Далее приложение обрабатывает эти готовые каналы (читает данные с тех, у кого появились, отправляет на те, кто готов принимать и т.д.), после чего цикл повторяется.

Благодаря селекторам один поток может обслуживать множество каналов ввода-вывода. Например, в сетевом сервере можно все клиентские соединения зарегистрировать в одном Selector и использовать единственный поток (или несколько, но гораздо меньше, чем число соединений) для общения с ними. Это контрастирует с классической моделью, где на каждое соединение обычно выделялся отдельный поток, блокирующийся на чтении. С селектором мы избегаем создания множества потоков: пока одни соединения неактивны, поток занимается другими, и переключение между ними происходит на уровне самого цикла select(), а не планировщика ОС.

На уровне кода Selector требует более сложной логики (нужно разбирать готовность каналов, хранить состояние протокола для каждого канала, ибо теперь взаимодействие фрагментировано – данные приходят порциями, а не сразу целым запросом). Но выгода – в масштабируемости: проверено на практике, что NIO-сервер на одном потоке может держать тысячи соединений с приемлемой производительностью, чего невозможно добиться с традиционным подходом без огромного количества потоков.

Рис. 3: Диаграмма, иллюстрирующая работу селектора: один поток следит за множеством каналов через объект Selector. Селектор позволяет выявить, на каком из каналов есть готовые данные, и передать управление обработке этого события. Таким образом, один поток может по очереди обслуживать несколько каналов ввода-вывода.

Подведем итог различиям: Java IO – это простая модель “поток данных/поток исполнения”, где чтение/запись блокирует поток до завершения операции. Java NIO – это модель «буфер/канал + неблокирующий мультиплексор (селектор)”, позволяющая достигать высокой эффективности при работе с большим числом соединений или большим объемом данных.

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

Чтение и запись файлов с помощью Java IO (пример)

Начнем с базовых операций с файлами в традиционном подходе Java IO. Для чтения текстовых файлов обычно используют классы FileReader или (предпочтительнее) BufferedReader для построчного чтения. Для записи – FileWriter или PrintWriter. Эти классы работают с символами, что удобно для текстовых данных (они учитывают кодировку). Есть и низкоуровневые классы FileInputStream/FileOutputStream, которые оперируют сырыми байтами – их обычно используют для бинарных файлов или совместно с DataInputStream/DataOutputStream для чтения/записи чисел, примитивных типов и т.п.

Пример чтения файла (IO): допустим, у нас есть текстовый файл input.txt, и мы хотим вывести его содержимое на консоль. Сделаем это построчно:

import java.io.*;

public class IoReadExample {
    public static void main(String[] args) throws IOException {
        File file = new File("input.txt");
        BufferedReader reader = new BufferedReader(new FileReader(file));
        try {
            String line;
            while ((line = reader.readLine()) != null) { 
                // Читаем файл построчно
                System.out.println(line);
            }
        } finally {
            reader.close(); // закрываем поток в блоке finally
        }
    }
}

В этом коде мы:

1. Открываем файл через FileReader (который является наследником Reader, работающего с символами).
2. Оборачиваем его в BufferedReader – это обеспечивает буферизацию и метод readLine(), позволяющий удобно читать по строкам.
3. В цикле читаем строки до конца файла (readLine() возвращает null при достижении EOF).
4. Каждую строку выводим на консоль.
5. Закрываем BufferedReader (что также закроет вложенный FileReader).

Обратите внимание, мы могли воспользоваться конструкцией try-with-resources (Java 7+) для автоматического закрытия, но для наглядности в примере показано закрытие вручную. Также, если бы нам нужно было читать не текст, а бинарные данные, мы могли использовать FileInputStream и метод read(byte[]) для чтения массива байт.

Пример записи файла (IO): теперь запишем какой-то текстовый файл. Используем FileWriter, обернем его в BufferedWriter для эффективности, либо воспользуемся PrintWriter для удобного вывода строк. Например, создадим файл и запишем в него несколько строк:

import java.io.*;

public class IoWriteExample {
    public static void main(String[] args) throws IOException {
        try (PrintWriter writer = new PrintWriter("output.txt", "UTF-8")) {
            writer.println("Hello, world!");     // Запись строки с переходом на новую строку
            writer.println("Привет, мир!");     // Можно писать и по-русски, указав UTF-8
            writer.printf("Число PI: %.3f%n", Math.PI); // форматированный вывод
        }
    }
}

Здесь показано использование try-with-resources для автоматического закрытия файла. Класс PrintWriter позволяет легко выводить текстовые данные, включая автоматическое добавление перевода строки через println и форматированный вывод через printf. Конструктор PrintWriter(String fileName, String csn) открывает указанный файл с заданной кодировкой (в данном случае UTF-8). После выполнения блока try файл будет закрыт автоматически. В итоге файл output.txt будет содержать указанные строки.

Стоит отметить: классические FileReader/FileWriter по умолчанию используют кодировку платформы, что не всегда желательно. В примере для PrintWriter мы явно указали кодировку UTF-8. Аналогично, чтобы явно задать кодировку при чтении, можно использовать InputStreamReader с указанием Charset, обернув FileInputStream. Либо использовать классы из NIO.2 (например, Files.newBufferedReader(path, charset)), о чем поговорим далее.

Коротко о буферизации в IO

В примерах мы использовали BufferedReader и упомянули BufferedWriter. Буферизация – важная техника в классическом IO для повышения эффективности. Чтение/запись по одному байту очень неэффективны, поэтому BufferedReader читает сразу большой блок символов (например, 8К) во внутренний буфер, и затем выдает вам данные по строчке или по символу без дополнительных системных вызовов. Аналогично, BufferedWriter накапливает данные и при заполнении буфера или при вызове flush() действительно пишет их разом в файл. Всегда рекомендуется оборачивать файловые потоки в buffered-версии (или использовать изначально классы, которые буферизуют). Впрочем, методы Files.readAllBytes() или Files.readAllLines() из нового API (Java 7+) сами внутри оптимизированы.

Итак, традиционный IO – это простые в использовании классы, легко реализующие распространенные задачи (прочитать файл, записать файл, скопировать поток и т.д.). Теперь посмотрим, как аналогичные операции выполняются с помощью NIO.

Но ведь и в IO есть буффер и в NIO есть буффер, в чем отличие?

Классический IO (java.io)

• Буфер – это внутренний или внешний вспомогательный объект, который облегчает работу с потоками.
• Пример: BufferedReader, BufferedInputStream, BufferedWriter и др.
• Буферизация делается для ускорения операций: читается/пишется сразу большой блок данных, чтобы не обращаться к файловой системе или сети по одному байту/символу.
• Но сам поток (InputStream, OutputStream, Reader, Writer) не требует буфера: вы можете читать по одному байту, можете обернуть поток в буфер, а можете и нет.
• Буфер IO обычно скрыт внутри обертки (BufferedReader и т.п.), сам поток ничего не знает о наличии буфера.

Архитектурно:

• Программа -> (BufferedReader) -> InputStream -> Файл

NIO (java.nio)

• Буфер (ByteBuffer, CharBuffer и др.) – обязательный участник всех операций!
• Каналы (FileChannel, SocketChannel, etc.) не читают/не пишут напрямую; вместо этого они читают данные в буфер или пишут из буфера.
• Вы явно управляете буфером: выделяете, управляете позициями, переворачиваете (flip), очищаете (clear).
• Буфер – самостоятельный объект, который вы передаете каналу.
• Буфер NIO – не просто оптимизация, а основной носитель данных между программой и каналом.

Архитектурно:

• Программа <-> ByteBuffer <-> FileChannel <-> Файл

Характеристика	Классический IO	NIO
Обязательность	Не обязателен (может быть без буфера)	Всегда обязателен (без буфера нельзя)
Управление	Буфер внутри обёртки, вы не управляете позициями	Вы сами создаёте, управляете позициями, flip/clear
Где находится	Внутри класса-обёртки (BufferedReader и др.)	В вашем коде — отдельный объект
Стиль	Последовательное чтение/запись, поток за потоком	Чтение/запись блоками, случайный доступ, управление памятью
Доп. возможности	Нет (кроме скорости)	DirectBuffer (off-heap), memory mapping, zero-copy, неблокирующий режим

Чтение и запись файлов с помощью Java NIO (пример)

Java NIO предоставляет несколько способов работы с файлами. Базовый – через класс FileChannel (java.nio.channels.FileChannel). Также в Java 7+ появился упрощенный файловый API (java.nio.file.Files и java.nio.file.Path), который мы обсудим отдельно в следующем разделе. Здесь сначала рассмотрим низкоуровневый подход с использованием каналов и буферов, чтобы понять принципы NIO.

Открытие файла: Для получения FileChannel можно использовать метод FileInputStream.getChannel() или FileOutputStream.getChannel(). Однако современный подход – использовать FileChannel.open(). Например:

Path path = Path.of("input.txt");
FileChannel fileChannel = FileChannel.open(path, StandardOpenOption.READ);

Так мы открыли канал для чтения файла (указав опцию READ). Для записи использовали бы WRITE и, при необходимости, CREATE (чтобы создать файл, если не существует) или TRUNCATE_EXISTING (обнулить существующий файл). Можно указывать несколько опций через запятую.

Пример чтения файла (NIO): прочитаем тот же input.txt с помощью FileChannel. Мы будем использовать буфер фиксированного размера (например, 1024 байта) и читать файл порциями:

import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.*;

public class NioReadExample {
    public static void main(String[] args) throws Exception {
        Path path = Path.of("input.txt");
        try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
            ByteBuffer buffer = ByteBuffer.allocate(1024);  // буфер на 1024 байта
            while (channel.read(buffer) > 0) {
                buffer.flip();  // переключаем буфер в режим чтения
                while (buffer.hasRemaining()) {
                    byte b = buffer.get();
                    System.out.print((char) b);  // выводим байты как символы
                }
                buffer.clear(); // очищаем буфер для следующей порции данных
            }
        }
    }
}

Данный код делает следующее:

1. Открывает FileChannel для файла. Используем try-with-resources, чтобы канал закрылся автоматически.
2. Создает ByteBuffer размером 1024 байта (это наш промежуточный буфер).
3. В цикле вызывает channel.read(buffer). Метод читает данные из файла прямо в буфер. Он возвращает количество прочитанных байт, либо -1, если достигнут конец файла. Мы читаем в цикл while, продолжающийся, пока читается хоть что-то (>0).
4. После успешного чтения необходимо переключить буфер в режим чтения: вызываем buffer.flip(). Изначально буфер был в режиме записи (после allocate его позиция = 0, limit = capacity). Когда FileChannel.read добавляет данные, позиция буфера сдвигается на число байт. flip() устанавливает limit = current position (то есть число байт, которые были прочитаны), а position = 0 – теперь от начала до этого лимита находятся свежие данные для чтения.
5. Вложенный цикл while (buffer.hasRemaining()) читает из буфера по одному байту и выводит как char. Здесь для простоты мы предполагаем, что файл – текст в ASCII/UTF-8, поэтому байт можно трактовать как символ. В общем случае для корректной обработки текста нужно использовать декодирование через CharsetDecoder или читать через Files.newBufferedReader – но мы фокусируемся на механике NIO.
6. После чтения содержимого буфера вызываем buffer.clear(). Этот метод не очищает сами данные (они остаются, просто будут перезаписаны), но сбрасывает позицию в 0 и устанавливает лимит = capacity, подготавливая буфер к следующему чтению в него.
7. Цикл повторяется, пока канал не вернет -1 (конец файла). Затем try-with-resources закрывает канал.

Как видим, этот код более низкоуровневый по сравнению с вариантом с BufferedReader. Мы вручную управляем буфером (flip, clear) и преобразуем байты в символы. Однако такой подход позволяет обрабатывать данные потоково без создания больших временных объектов (например, можно сразу в буфере искать какие-то паттерны, или передавать его содержимое куда-то еще). Кроме того, FileChannel предоставляет методы для произвольного доступа: например, channel.position(long newPos) чтобы установить позицию для следующего чтения/записи, или метод read(ByteBuffer dst, long position) для чтения данных из файла с определенной позиции (не изменяя текущую позицию канала). Это эквивалентно операциям seek на файловых дескрипторах. Со стандартными InputStream/Reader добиться такого можно было только заново открывая файл или используя RandomAccessFile.

Пример записи файла (NIO): теперь запишем файл с использованием FileChannel. Запись происходит схожим образом, но мы кладем данные в буфер как источник и вызываем channel.write(buffer). Предположим, мы хотим записать тот же текст, что в примере с IO:

import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.charset.StandardCharsets;
import java.nio.file.*;

public class NioWriteExample {
    public static void main(String[] args) throws Exception {
        String text = "Hello, world!\nПривет, мир!\n";
        ByteBuffer buffer = ByteBuffer.wrap(text.getBytes(StandardCharsets.UTF_8));
        // Открываем канал на запись (с созданием файла или заменой)
        try (FileChannel channel = FileChannel.open(Path.of("output.txt"), 
                StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.TRUNCATE_EXISTING)) {
            channel.write(buffer);
        }
    }
}

Здесь мы создали ByteBuffer сразу из массива байт строки с помощью ByteBuffer.wrap(...). Это удобный метод, который оборачивает существующий массив байт в буфер (позиция устанавливается в начало массива, лимит – в конец массива, буфер в режиме чтения этих данных). Далее открываем FileChannel с опциями CREATE (создать файл, если не существует), WRITE (открыть на запись) и TRUNCATE_EXISTING (если файл существует, очистить его содержимое). Вызываем channel.write(buffer), что запишет содержимое буфера в файл. После окончания блока try канал закроется. Если размер данных больше, чем буфер, или запись может частично записать данные (например, в неблокирующем режиме или при очень большом объеме), channel.write нужно вызывать в цикле, пока буфер не опустеет (пока buffer.hasRemaining() истина). В данном примере весь текст помещается в буфер сразу.

Отличие от примера с IO: там мы напрямую вызывали println для каждой строки, здесь же мы сформировали весь вывод в строку и перевели в байты, записав разом. Можно было делать и построчно: например, вызвать channel.write(ByteBuffer.wrap("Hello, world!\n".getBytes(...))); несколько раз. Каждый вызов write будет писать от текущей позиции файла, продвигая ее на число записанных байт. FileChannel также поддерживает запись по заданной позиции: метод channel.write(ByteBuffer src, long position) – он запишет данные начиная с указанного места, не трогая текущий offset канала. Это позволяет, например, записывать в разные части файла параллельно (при использовании нескольких каналов или при синхронизации).

Особенности и продвинутые возможности FileChannel

Класс FileChannel предлагает несколько методов, которых нет в классическом FileOutputStream/Writer:

• Методы transferTo и transferFrom: Это методы для копирования данных между каналами непосредственно. Например, fileChannel.transferTo(0, fileChannel.size(), targetChannel) скопирует содержимое одного канала (файла) в другой (например, в канал сокета) без промежуточного буфера на уровне пользователя. Такие методы могут использовать оптимизации ОС, в частности на UNIX/Linux – системный вызов sendfile(), позволяющий передать данные из файла в сетевой сокет минуя копирование через буфер приложения (так называемый zero-copy). Zero-copy значительно ускоряет передачу больших файлов по сети, уменьшая нагрузку на CPU, так как данные не копируются лишний раз между ядром и пользовательским приложением. Это преимущество NIO для таких сценариев: например, реализуя свой веб-сервер или файловый сервер, можно слать файлы через FileChannel.transferTo, что будет эффективнее, чем читать их в буфер Java и потом писать в сокет вручную.
• Memory-mapped I/O: FileChannel может создавать memory-mapped file – отображение файла в память. Метод FileChannel.map() возвращает MappedByteBuffer, который представляет участок файла, отображенный в памяти. Чтение/запись в этот буфер фактически работает с памятью напрямую, а ОС в фоне загружает соответствующие части файла с диска (и выгружает, если нужно). Memory-mapped I/O бывает быстрее обычного чтения для определенных задач (например, случайный доступ по файлу, работа с очень большими файлами) и позволяет работать с файлами как с большим массивом байт. Однако с ним связаны нюансы (границы памяти страницы, необходимость аккуратно работать с указателями, и то, что освобождение памяти происходит при сборке мусора MappedByteBuffer, либо через вспомогательные костыли). Тем не менее, это мощный инструмент NIO.

Таким образом, NIO-файловый ввод-вывод через FileChannel более низкоуровневый и предоставляет возможности для оптимизаций (например, zero-copy, memory mapping), а также более гибкий доступ к файлам (позиционирование, параллельный доступ). Однако для простых случаев (прочитать небольшой файл целиком, записать строку в файл) такой подход сложнее, чем использование простых Files.readAllBytes или PrintWriter. В следующих разделах мы обсудим, как новый файловый API Java 7 упростил многие задачи и сравним его с библиотекой Apache Commons IO.

Ограничения и производительность IO и NIO (и особенности Linux)

Когда речь заходит о производительности ввода-вывода, важно понимать контекст: размер данных, число параллельных операций, характеристики платформы (ОС, файловая система, наличие SSD или сетевого хранилища и т.д.). Ниже мы обсудим, в чем заключаются ограничения классического IO, как NIO адресует эти проблемы, и каких результатов можно ожидать. Особое внимание уделим аспектам, связанным с ОС Linux, так как она часто используется для серверных Java-приложений.

Производительность классического IO

Классический IO (java.io) прост в использовании, но может становиться узким местом при больших объемах данных или множестве одновременных операций. Основные ограничения:

• Блокирующий характер: как уже отмечалось, каждый поток, выполняющий I/O, простаивает в ожидании данных или возможности отправить данные. На Linux (и других ОС) операции с файлами и сокетами по умолчанию блокируют поток. Это значит, что если приложение должно обслуживать, скажем, 1000 одновременных клиентов, модель с блокирующим IO потребует 1000 потоков (что на практике крайне неэффективно из-за расходов памяти и планирования).
• Системные вызовы на каждый байт/символ (без буферизации): Если программно не использовать буферы (BufferedReader/Writer), то чтение по одному байту (InputStream.read()) приводит к системному вызову read(2) на каждый байт, что очень медленно. Обычно программисты избегают этого, всегда буферизуя. Но даже при буферизации есть стоимость переключения из пользовательского режима в режим ядра при каждом заполнении буфера.
• Копирование данных: При классическом подходе данные обычно копируются несколько раз: с диска в ядро, затем из ядра в пользовательский буфер, затем, возможно, из одного буфера в другой. Например, чтение файла и тут же запись его в сеть: приложение получило байты от ядра в свой массив, затем передало их сокету, что вызвало копирование из массива обратно в буфер ядра, и потом ядро отправляет по сети. Эти лишние копирования съедают CPU. NIO решает это через transferTo/transferFrom (zero-copy).
• Ограниченная функциональность старого API: класс java.io.File (не путать с FileInputStream) – старый класс для работы с файловой системой – не предоставлял прямых средств массового копирования файлов, рекурсивного обхода каталогов, отслеживания изменений файловой системы и пр. Приходилось многое реализовывать вручную, что чревато неэффективными реализациями.

Нужно отметить, что сами по себе потоки Java IO не “медленные” – они обертка над системными вызовами ОС. Если читать файл крупными блоками через FileInputStream/BufferedInputStream, скорость будет сопоставима с Си-шным чтением через read(). Однако Java IO не давал возможностей, как избежать лишних копий или как эффективно управлять множеством соединений – для этого и придумали NIO.

Производительность NIO

Java NIO стремится к более высокой производительности и масштабируемости за счет:

• Неблокирующего ввода-вывода и селекторов: Позволяет снизить количество потоков, необходимых для обработки множества соединений. Один поток (например, в Linux он будет использовать под капотом epoll или select системный вызов) может чеканить события на сотнях сокетов. Это масштабируется лучше, чем сотни потоков с блокирующим I/O. (Замечание: на современных JVM появились виртуальные потоки (Project Loom), нивелирующие проблему блокирующего IO – т.к. блокировка виртуального потока не блокирует реальный поток ОС. Но это тема отдельного разговора, и NIO селекторы все равно остаются эффективным решением для классического подхода с ограниченным числом OS-потоков.)
• Крупноблочного и прямого ввода-вывода: Работа через ByteBuffer позволяет читать/писать данные порциями нужного размера. Можно использовать прямые буферы (ByteBuffer.allocateDirect()), которые выделяются вне кучи Java – такие буферы могут быть эффективнее при взаимодействии с native кодом. Например, при чтении файла в прямой буфер JVM может попросить ОС записать данные прямо в этот буфер, минуя копирование через временный массив в куче. (Хотя на практике JVM все равно может использовать внутренние оптимизации, но идея – direct buffer может быть расположен так, чтобы облегчить DMA и сократить копирование.) Википедия отмечает: “NIO buffer… implementation may select memory for alignment or paging… allowing buffer contents to occupy the same physical memory used by OS for native I/O, thus eliminating the need for additional copying. В большинстве ОС, если память обладает нужными свойствами, передача может происходить без участия CPU”. Это и есть суть zero-copy: использование прямого буфера + системного вызова, который умеет передать данные из файла в сетевой сокет, например, минуя пользовательский код. NIO предоставляет инструменты, которыми может воспользоваться OS для таких оптимизаций.
• Memory Mapped Files: как описано выше, memory mapping позволяет очень быстро обрабатывать большие файлы, отдав работу по загрузке страниц памяти ОС. Это тоже форма zero-copy: файл отображается в адресное пространство, и чтения страниц выполняются по требованию (page fault) без явных read() операций. Многие задачи, как парсинг очень больших логов, могут выиграть от memory mapping. Но есть и ограничения: например, размер одного MappedByteBuffer ограничен Integer.MAX_VALUE (около 2 ГБ), то есть для файлов >2ГБ нужно делать несколько маппингов. Также, освобождение MappedByteBuffer (снятие отображения) – нюансный момент, требующий либо вызова cleaner() через reflection (неофициально), либо ожидания сборщика мусора. Тем не менее, NIO дает выбор этих инструментов для повышения производительности.
• Асинхронный файл I/O (NIO2): класс AsynchronousFileChannel (Java 7) позволяет запускать операции чтения/записи в фоновом режиме с уведомлением (через Future или CompletionHandler). В Linux реализация по умолчанию – через пул потоков-воркеров, которые внутри делают обычный read, ибо полноценный asynch I/O для файлов (aio, io_uring) не был готов в эпоху Java 7. Однако в будущем, возможно, реализация улучшится с использованием новых системных API (например, упомянутый io_uring). Уже сейчас ведутся разговоры о поддержке io_uring в JDK для файлов и сетевых каналов, что на Linux могло бы дать настоящую асинхронность файлового ввода-вывода.

Каков практический выигрыш? В Single-thread сценариях чтения/записи одного большого файла NIO может быть немного быстрее IO, но разница не всегда кардинальна. Например, бенчмарк записи 1 ГБ данных показал: FileChannel записал за ~431 мс, а FileOutputStream за ~556 мс (в тех условиях). Выигрыш ~20-25% объясняется тем, что FileChannel может использовать более крупные операции или напрямую работать с памятью (а FileOutputStream, возможно, вызывал больше переключений на уровень ядра или имел накладные расходы синхронизации). При работе с очень большими файлами или высокой нагрузке эта разница растет. Кроме того, если задействовать transferTo (zero-copy), то при передаче файла по сети экономия CPU может быть существенной – вплоть до двукратного снижения загрузки CPU на операцию, поскольку исключаются копирования между ядром и приложением.

С другой стороны, NIO не всегда быстрее IO для всех случаев. Например, если у вас простое однопоточное приложение, которое читает маленькие текстовые файлы целиком, использование BufferedReader и readLine может оказаться даже быстрее в разработке и сопоставимо по скорости с вариантом на FileChannel – потому что накладные расходы JVM/Java-кода и так малы сравнительно с операцией чтения с диска. Иногда разработчики предполагают, что NIO автоматически быстрее, но это не гарантировано – все зависит от конкретного сценария. Например, есть случаи, где BufferedInputStream с оптимальным буфером дает ту же пропускную способность, что и FileChannel с ByteBuffer, поскольку узкое место – диск, а не обертка Java. Поэтому всегда полезно профилировать под свою задачу.

Ограничения NIO и подводные камни:

• Сложность кода: Как мы видели, код с буферами и селекторами более сложен. Неправильное использование (flip/clear и т.д.) приводит к ошибкам. Работа с селекторами – это фактически написание небольшого конечного автомата (state machine) для обработки разных фаз протокола. Для начинающих это может быть трудным. Поэтому NIO хорош в опытных руках и для сложных систем, но не стоит применять его без необходимости (overengineering).
• DirectBuffer управление памятью: DirectByteBuffer выделяются вне heap и управляются JVM неявно. Их избыточное использование может привести к исчерпанию внекучевой памяти (например, если создавать много direct буферов и полагаться на GC, который не сразу их освободит). Надо уметь либо явно их освобождать (методом unsafe, что небезопасно), либо реиспользовать, либо настроить -XX:MaxDirectMemorySize.
• Не всеми возможностями ОС можно воспользоваться через Java NIO: Например, Linux имеет syscalls sendfile, mmap (они используются), но более новые, такие как splice или io_uring – пока напрямую Java их не использует (на момент 2025 года). FileChannel.transferTo на Linux задействует sendfile, но, например, на Windows он вынужден делать копирование вручную, так как аналогично эффективного системного вызова нет (был TransmitFile, но подробности реализации в JVM специфичны).
• Файловый ввод-вывод остается зависящим от ОС: Даже неблокирующий NIO не решает проблему “медленных дисков”. На Linux чтение файла – блокирующая операция на уровне ядра (если не использовать AIO). Поэтому, даже используя NIO, поток будет ждать чтения с диска. В серверных приложениях это часто не критично, так как основное время – на сеть, но имейте в виду: файловые операции могут внезапно стать узким местом. Например, логгирование: запись логов – это обычно диск. И даже на фоновых потоках, если диск медленный, логгирование может отставать. В Linux вызов fsync (сброс на диск) – очень дорогой и блокирующий, он будет блокировать и NIO-канал тоже. В современных системах, конечно, скорость SSD высока, но задержки и блокировки на уровне ОС никуда не делись.

Особенности Linux: Раз уж речь, приведем пару Linux-специфичных моментов:

• Linux предоставляет интерфейс inotify для отслеживания изменений в файловой системе. Java NIO.2 WatchService на Linux использует inotify. Это значит, что события о изменениях файлов/директорий приходят из ядра, и WatchService их собирает. При очень частых изменениях (например, тысячи файлов в секунду) внутренний буфер ядра для событий может переполниться, и WatchService бросит событие OVERFLOW – т.е. предупредит, что что-то утеряно. Это ограничение системы: WatchService на Linux может терять события при перегрузке. Решение – либо снижать частоту (например, не обрабатывать такие массивные изменения напрямую), либо увеличивать буферы ядра (параметры /proc), либо использовать альтернативы (Apache Commons IO мониторинг – о нем ниже). Также WatchService не умеет отслеживать сетевые файловые системы (NFS и т.п.) – на Linux inotify не работает для удаленных дисков. В таких случаях WatchService по спецификации может перейти в режим опроса, но реализовано это или нет – зависит от JVM.
• Linux (начиная с 2.6) оптимизирует работу с файлами через страничный кэш. Потому повторное чтение того же файла из NIO или IO будет быстрое (данные уже в памяти). NIO позволяет получить, например, “большой листинг каталога в буфер быстрее, чем старый File” – это упоминается в контексте, что новый API может использовать эффективные вызовы наподобие readdir и читать большими блоками.
• В многопоточной среде на Linux (и вообще POSIX) ввод-вывод на один и тот же файл должен синхронизироваться во избежание гонок. Java FileChannel сам по себе не делает весь I/O атомарным – если два потока будут писать в один FileChannel, записи перемешаются (если не позиционироваться явно). На уровне ОС, конечно, каждая отдельная write атомарна, но последовательность не координируется. Поэтому, если вам нужно безопасно писать из нескольких потоков в файл, нужно либо внешне синхронизировать, либо использовать механизмы file lock (у FileChannel есть lock()/tryLock() для советующих блокировок файла).

В целом, производительность NIO проявляет себя в масштабируемости – когда надо работать с большим числом соединений/файлов одновременно, или с очень большим объемом данных. В ситуациях попроще разницы может быть мало, и иногда проще остаться на IO. Далее мы обсудим, какие практические рекомендации можно дать по выбору IO vs NIO, а также посмотрим на сравнение нового файла API Java 7 и библиотеки Apache Commons IO.

Cводная таблица отличий и характеристик Java IO vs NIO

Характеристика	Java IO (java.io.*)	Java NIO (java.nio.*)
Дата появления	Java 1.0	Java 1.4 (NIO), Java 7 (NIO.2, java.nio.file.*)
Базовая абстракция	Потоки (Streams): InputStream, OutputStream, Reader, Writer	Каналы (Channels), Буферы (Buffers), Селекторы (Selectors)
Модель данных	Потоковая (Stream-oriented)	Буферная (Buffer-oriented)
Буферизация	Не обязательна (обычно через Buffered* обёртки)	Обязательна (все операции идут через Buffer)
Управление буфером	Неявное, внутри обёрток, автоматическое	Явное, разработчик управляет pozition/limit/flip/clear
Блокирующий режим	Только блокирующий	Есть поддержка неблокирующего режима (Selector)
Многопоточность	Обычно поток на соединение или файл	Один поток может обслуживать много каналов через Selector
Произвольный доступ	Только через RandomAccessFile	FileChannel поддерживает произвольный доступ, позиционирование
Zero-Copy (sendfile, mmap)	Нет	Да (transferTo, transferFrom, memory-mapped files)
Работа с большими файлами	Ограничено	Memory-mapped I/O, эффективная работа с большими файлами
Асинхронность	Нет	Есть (AsynchronousChannel в NIO.2)
API для файловой системы	java.io.File	java.nio.file.Path, Files (сильнее, богаче, POSIX-метаданные)
Обработка событий	Нет	Есть (Selector, WatchService для файловых событий)
Использование	Простые скрипты, небольшие задачи, чтение/запись текстовых/бинарных файлов	Высокопроизводительные серверы, параллельная обработка, большие файлы
Простота кода	Максимально просто	Более низкоуровневый, требует управления состоянием
Поддержка неблокирующих сокетов	Нет	Да (SocketChannel + Selector)
Рекомендации по использованию	Простой ввод-вывод, чтение файлов, не критично масштабирование	Серверы, высокая нагрузка, масштабируемые приложения
Расширяемость	Меньше возможностей	Больше возможностей для оптимизации

Сравнение Java NIO.2 (java.nio.file) и Apache Commons IO

Начиная с Java 7, в платформе появился новый файловый API – пакет java.nio.file с основными классами Path и утилитным классом Files. Этот API (неофициально называемый NIO.2) во многом закрыл пробелы старого java.io.File и ввел удобные методы для файловых операций. До появления Java 7 разработчики часто использовали сторонние библиотеки, такие как Apache Commons IO, чтобы упростить работу с файлами и потоками – например, для рекурсивного удаления директорий, копирования файлов, чтения всего файла в строку и т.д. Теперь же значительная часть этой функциональности доступна средствами стандартной библиотеки.

Рассмотрим основные моменты сравнения:

Новый файловый API (NIO.2, Java 7+) – Path и Files

Класс Path: заменяет собой java.io.File как представление пути к файлу или директории. Это более современная и гибкая абстракция. Например, Path понимает разные файловые системы, можно легко получить относительный путь, родительский, проверять начало/конец пути, и пр. Метод Paths.get("...") (в Java 11+ можно Path.of("...")) создает объект Path. В отличие от File, Path не имеет методов типа delete или renameTo – вместо этого все операции вынесены в утилитный класс Files.

Класс Files: содержит статические методы для большинства рутинных операций с файлами: чтение/запись, копирование, перемещение, создание директорий, работа с потоками, и т.д. Несколько примеров того, что появилось в Java 7+:

• Files.readAllBytes(path) – прочитать весь файл в byte[].
• Files.readAllLines(path, charset) – прочитать все строки в список List<String>.
• Files.newBufferedReader(path, charset) / Files.newBufferedWriter(path, charset) – получить BufferedReader/Writer для файла (альтернатива FileReader, с заданием кодировки).
• Files.copy(InputStream, targetPath, StandardCopyOption.REPLACE_EXISTING) – скопировать из входного потока в файл. Или перегрузка Files.copy(sourcePath, OutputStream) – из файла в выходной поток. Также Files.copy(sourcePath, targetPath, options) – копирование файла на уровне ОС (копирует атрибуты, по возможности эффективно).
• Files.move(sourcePath, targetPath, options) – переместить/переименовать файл или директорию (в том числе может использовать атомарный rename, если это одна ФС).
• Множество методов для атрибутов файла: Files.getAttribute(path, "size"), Files.getLastModifiedTime(path), Files.isSymbolicLink(path), Files.getPosixFilePermissions(path) и т.д. – раньше надо было использовать File или даже вызывать процессы ОС для такого.
• Работа с ссылками (symlink): новый API позволяет отличить симлинк от реального файла, читать/создавать символические ссылки через Files.createSymbolicLink и Files.readSymbolicLink.
• Перебор содержимого директорий: Files.newDirectoryStream(path) дает DirectoryStream<Path> – итератор по файлам в директории (с возможностью фильтровать по маске). В Java 8+ появилась еще более мощная утилита: Files.walk(path) – возвращает Stream для дерева каталогов (рекурсивно), можно указать глубину. С помощью этого легко делать обходы файловой системы (например, Files.walk(path).filter(Files::isRegularFile).count() – посчитать все файлы в поддиректориях).
• WatchService: пакет java.nio.file включает WatchService для отслеживания изменений. Мы уже обсуждали: можно регистрировать Path (только директории) на события ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY и получать уведомления. Код с WatchService – это классический producer/consumer: отдельный поток ожидает watchService.take() и потом в цикле обрабатывает события. Это значительно упрощает задачи типа “запустить и ждать, когда появится новый файл в папке”. Apache Commons IO до появления WatchService предлагал свой FileAlterationMonitor (см. далее), но теперь есть встроенное средство. Однако, как упоминалось, WatchService опирается на возможности ОС. На Windows он работает через Windows API (ReadDirectoryChangesW), на Linux – через inotify, на MacOS – через kqueue. Везде своя специфика и ограничения (в Linux – переполнение буфера событий, в Windows – возможны проблемы с сетевыми шарами и т.д.). Тем не менее, для большинства задач WatchService удобен и не требует дополнительных зависимостей.

Почему новый API лучше старого java.io.File: Приведем коротко, что не умел старый File и решил новый API:

• File плохо работал с символическими ссылками – например, метод file.isDirectory() возвращал false для симлинка на директорию, даже если он указывает на папку. NIO.2 предоставляет методы и опции (LinkOption.NOFOLLOW_LINKS) для получения поведения, какого вы хотите: можно проверять сам линк или цель.
• File не предоставлял удобного способа получить стандартные атрибуты (время модификации, права доступа). Нужно было использовать File и метод lastModified (возвращает long) и прочие урезанные методы. NIO.2 дает целый пакет java.nio.file.attribute с интерфейсами для POSIX прав, для DOS атрибутов, и статические методы Files.getAttribute/ setAttribute.
• File вел себя по-разному на разных ОС (особенно в части разделителей путей, корневых путей). Path решает много вопросов, плюс поддерживает разные файловые системы (можно получить объект FileSystem для, например, zip-файла или сетевого FS).
• Через File было неудобно выполнять элементарные операции типа копирования. Нужно было либо читать/писать вручную (что неэффективно), либо использовать FileChannel.transferTo. Теперь же – один вызов Files.copy. Аналогично с удалением директории с содержимым: File.delete() удалит только пустую директорию, а рекурсивно – нужно было писать рекурсию. Сейчас можно, например, использовать Files.walk и удалять. Либо воспользоваться Path методом toFile() и тогда FileUtils.deleteDirectory из Commons IO – но опять же, это внешний либ.

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

Apache Commons IO

Apache Commons IO – популярная библиотека (под Apache License) с множеством утилит для ввода-вывода. Ее основные возможности:

• FileUtils – класс с статическими методами для работы с файлами и директориями: копирование (FileUtils.copyFile, copyDirectory), удаление (forceDelete), сравнение (contentEquals), вычисление размера директории (sizeOfDirectory), очистка директории, создание структуры директорий, и т.п. Многие из этих методов появились до Java 7, восполняя недостатки java.io.File. Сейчас аналогичные функции есть в Files, но FileUtils иногда предлагают более короткий код. Например, чтение файла в строку: FileUtils.readFileToString(file, StandardCharsets.UTF_8) – до Java 11 (где появился Files.readString) это был очень удобный способ.
• IOUtils – утилиты для потоков: методы вроде toString(InputStream, charset) – прочитать InputStream полностью и превратить в String; copy(InputStream, OutputStream) – копирование потока (с внутренним буфером); closeQuietly – тихо закрыть, подавляя исключения; и прочие. Многие из них сейчас можно делать через Files.copy или try-with-resources. Но IOUtils иногда экономит несколько строк кода.
• Мониторинг файловой системы: Commons IO предоставляет FileAlterationObserver и FileAlterationMonitor. Это аналог WatchService, но работающий на всех платформах единообразно за счет опроса (polling). Идея: библиотека запускает таймер (отдельный поток), и раз в заданный интервал сканирует содержимое директории, сравнивая с предыдущим состоянием. Различия вызывают колбэки (onFileCreate, onFileDelete, onFileChange). Преимущество такого подхода – независимость от ОС: он будет работать и на сетевых шарах, и на любой FS, просто обходя каталог. Также нет риска переполнения буфера – события не теряются, просто обнаруживаются с некоторой периодичностью. Недостаток – постоянная нагрузка на CPU, даже когда ничего не происходит (каждый опрос – чтение каталога). При большом количестве файлов и малом интервале это может нагружать систему больше, чем event-based подход WatchService. Commons IO мониторинг удобен, когда нужны гарантии (пусть с задержкой) и простота – например, проверять раз в 10 секунд, не появился ли новый файл. WatchService же подходит для быстрого реагирования (событие сразу приходит), но с ограничениями (локальные FS, без перегрузки). В таблице сравнения отмечено: Commons IO поддерживает сетевые диски и работает и на Windows, и на Unix, не нагружает CPU только пропорционально частоте опроса, тогда как WatchService не требует постоянного CPU, но может терять события при всплеске.
• Другие утилиты: Commons IO имеет классы FilenameUtils (работа с именами файлов, расширениями, путями как строками), FileFilter реализации (например, WildcardFileFilter для фильтрации по шаблону), EndianUtils (чтение данных в заданной endian), FileSystemUtils (например, свободное место на диске) и прочее. Многие из них появились, когда в Java не было удобных способов. Сейчас часть есть в NIO (например, утилиты для имен файлов можно заменить на методы Path, свободное место – FileStore.getUsableSpace()). Но Commons IO все еще находит применение, особенно в стартапах с Java 8, или когда уже подтянута в проект.

Рис. 4: WatchService vs Apache Commons IO Monitoring

Сравнение и выбор: Если вы на актуальной Java версии (21 и выше), большинство задач по файлам можно решить средствами java.nio.file и вам не нужна Commons IO. Зависимость лишних библиотек усложняет проект, поэтому предпочитают стандартные средства. Тем более, новые методы вроде Files.writeString(Path, CharSequence) (Java 21) делают то же, что FileUtils.writeStringToFile.

Когда может иметь смысл использовать Commons IO:

• Если вы поддерживаете совместимость с Java 6 или <7 (крайне редко сейчас).
• Если у вас уже используется Commons IO и переписывать код дорого.
• Если вы нуждаетесь в FileAlterationMonitor (polling) вместо WatchService – например, у вас сетевой диск, где WatchService не работает корректно.
• Некоторые специфичные утилиты Commons IO, которых нет в JDK. Например, Tailer – класс, позволяющий следить за концом файла (как утилита tail -f). Хотя это тоже можно сделать через WatchService + RandomAccessFile, но Commons IO предоставляет готовый Tailer.

В плане производительности Commons IO не дает преимуществ – внутри она использует те же потоки/каналы. Иногда даже бывает, что FileUtils.copyFile работает чуть медленнее, чем Files.copy, потому что последний может использовать sendfile при возможности, а Commons IO читает/пишет буфер в 16KB. Но разница небольшая. Commons IO больше про удобство.

Подведем черту: Java NIO.2 vs Apache Commons IO: Новый файловый API Java удовлетворяет большинство потребностей, обеспечивая и высокоуровневые утилиты, и низкоуровневый контроль. Apache Commons IO остается полезным в некоторых сценариях (особенно мониторинг на нескольких платформах без углубления в нюансы ОС). Но если ваш проект стремится к минимизации зависимостей и вы используете современную Java, отдавайте предпочтение встроенному API.

Когда выбирать IO, а когда NIO?

Наконец, обобщим рекомендации по выбору подхода для различных сценариев:

• Простое чтение/запись файлов, утилиты для файлов: Используйте Java NIO.2 (java.nio.file.Files/Path). Он предоставляет как удобство (методы для чтения всего файла, копирования и пр.), так и потенциал высокой производительности. Классический IO тоже справится, но зачем писать больше кода, если есть готовые методы. Apache Commons IO может помочь, но в новых версиях Java зачастую лишний.
• Обработка текстовых файлов построчно: Если файл небольшой или средний – можно считать все строки через Files.readAllLines. Если файл большой – используйте потоковую обработку: например, Files.newBufferedReader и читайте readLine() внутри цикла (по сути это та же классическая модель, но используя новые классы). Или Files.lines(path) (Java 8) – он вернет Stream стрим, удобно с лямбдами, но не забудьте закрыть стрим (он откроет файл). Классический BufferedReader так же хорошо справится. Разницы особой нет – под капотом Files.newBufferedReader создает тот же BufferedReader.
• Чтение/запись двоичных файлов: Если нужны простые операции (читать весь файл, или поблочно) – можно использовать Files.readAllBytes / Files.write (они внутри оптимизированы). Если нужна работа со структурированными данными – возможно удобнее DataInputStream/DataOutputStream. Но и ByteBuffer в NIO умеет читать примитивы (методы getInt, getLong при соответствующем byte order). Классический IO проще в использовании для записей примитивов (DataOutputStream.writeInt, etc.), а NIO ByteBuffer может быть эффективнее, если вы делаете много вычислений с этими данными. Но в общем, для обычных двоичных файлов можно и не усложнять – IO подойдет.
• Обработка очень больших файлов (размером в гигабайты): Здесь NIO может дать выгоду. Например, memory-mapped I/O позволит вам обрабатывать файл частями без загрузки целиком. Или FileChannel чтение позволит эффективно читать блоками фикс.размера и, скажем, параллельно обрабатывать их (с несколькими потоками). Классический IO тоже может читать порциями, но NIO дает больше контроля и возможностей (тот же random access с channel.position). Если файл настолько большой, что не помещается в память, все равно придется читать по частям – тут либо BufferedInputStream+RandomAccessFile, либо FileChannel – второе предпочтительнее из-за поддержки Long позиций (RandomAccessFile ограничен?), и опять же, memory map.
• Сетевое программирование (сокеты):
  • Если вы пишете простой клиент или небольшой сервер, где количество соединений невелико (до сотен) – можно спокойно использовать классические Socket/ServerSocket с потоками. Код будет проще, читабельнее. С появлением виртуальных потоков (Project Loom, Java 19+) даже тысячи соединений можно держать с блокирующим IO, не выделяя тысячи OS-потоков – поэтому старый модель возвращается в игру для высоких нагрузок.
  • Если вы пишете высокопроизводительный сервер (скажем, игровой сервер, биржевой шлюз, etc.) на стандартных потоках и не используете Loom, то Java NIO – практически единственный путь эффективно работать с большим числом соединений. Комбинация Selector + SocketChannel позволит одному потоку обслуживать много клиентов. Это сложно, но себя оправдывает в определенных случаях (например, фреймворки Netty, Mina построены поверх NIO, скрывая часть сложности).
  • Если вам нужна ** multicast, неблокирующий UDP** – NIO предоставляет DatagramChannel с неблокирующим режимом (поддержка multicast через joinGroup). Это тоже плюс NIO.
  • Асинхронное взаимодействие: в Java 7+ есть AsynchronousSocketChannel. Он позволяет работать с сокетами в стиле “future” или с колбэками. Внутри на Windows это IOCP, на Linux – epoll + threadpool. Это, по сути, альтернатива вручную управлять Selector-ом. Если вам ближе модель “отправил запрос на чтение и получил callback” – можете попробовать AsynchronousSocketChannel. Но многие библиотеки (Netty, Akka) предпочитают селекторы + свои потоки.
• Конвейерная обработка данных/трубопроводы (Pipes): Java NIO имеет класс Pipe (двунаправленный канал между двумя потоками в одном JVM) – для специфических случаев. Обычно не сильно нужен.
• Логирование и запись больших логов: Логи обычно пишут классическим IO (через java.util.logging, Log4j и т.п., они внутри используют FileOutputStream). NIO здесь может помочь memory-mapping-ом, если нужно очень быстро читать/искать по логам. Но для записи логов NIO не особо нужен – важнее, насколько часто вызывается fsync.
• Если нужен Zero-Copy (например, прокси-сервер, перекачивающий данные): Однозначно NIO: transferTo/transferFrom позволят переслать данные напрямую. Например, файловый сервер, посылающий файл клиенту – вместо цикла чтения/записи можно вызвать один метод transferTo (с небольшим циклом, если файл >2ГБ, по ограничению). Это значительно разгрузит CPU.
• Совместное использование с существующими библиотеками: Если вы, скажем, используете библиотеку, которая ожидает InputStream/OutputStream (например, для распаковки архивов ZipInputStream), то и работайте с IO. NIO FileChannel можно превратить в InputStream (через Channels.newInputStream(channel)), но это дополнительная морока. Проще открыть FileInputStream и отдать библиотеке. То есть NIO не отменяет IO – они дополняют друг друга.
• Опыт команды: нельзя не упомянуть, что писать и отлаживать NIO код сложнее. Если команда новичков, лучше не лезть в селекторы, пока не появится реальная потребность (например, производительность перестала устраивать и профилирование показало, что вы тратите ресурсы впустую на ожидание). Многие высокоуровневые фреймворки скрывают детали: например, использование сервлетов (классический веб) historically – блокирующая модель, но application server внутри мог использовать NIO (например, Tomcat NIO Connector). Сейчас появились reactive фреймворки (Netty, Vert.x, etc.), которые прямо построены на NIO и вынуждают вас писать неблокирующий код и использовать Future/Callback. Это оправдано для очень нагруженных систем. Но для простых сервисов лишняя сложность может привести к ошибкам и даже ухудшению производительности, если неправильно использовать (например, неправильное масштабирование Selector threads).

Cводная таблица “Когда выбирать IO, а когда NIO”

Сценарий / Требование	IO (java.io.*)	NIO (java.nio.*)
Чтение/запись небольших файлов (text/bin)	Лучше (проще)	Можно, но сложнее
Простая файловая обработка без требований к производительности	Лучше	Можно, но избыточно
Чтение/запись больших файлов (сотни МБ и ГБ)	Можно, но медленно	Эффективнее (memory-mapped, блоки)
Работа с потоками данных (InputStream/OutputStream)	Да	—
Обработка текстовых файлов построчно	Да	Можно, но менее удобно
Масштабируемый сетевой сервер (сотни/тысячи соединений)	—	Selector, SocketChannel
Высокопроизводительный файловый сервер / прокси (zero-copy)	—	transferTo, memory-mapped
Асинхронная/неблокирующая работа с сетью	—	Да (Selector, AsynchronousChannel)
Произвольный доступ к файлам (seek/position)	Можно (RandomAccessFile)	Да (FileChannel)
Файловый мониторинг/реакция на изменения	—	WatchService
Нужна минимальная сложность кода/легко читать	Лучше	—
Код должен быть максимально переносимым/простым	Да	—
Требуется точечная оптимизация производительности	—	Да
Совместимость с библиотеками, ожидающими InputStream/OutputStream	Да	Можно через адаптер
Совместимость с Java <1.4	Да	—
Реактивные фреймворки (Netty, Vert.x, Akka)	—	Только NIO
Большое количество параллельных операций I/O	—	Лучше через Selector/Async

Заключение

В статье мы подробно рассмотрели особенности и различия двух основных подходов работы с вводом-выводом в Java – классического IO (java.io) и современного NIO (java.nio). Несмотря на то, что оба подхода выполняют схожие задачи (чтение и запись файлов, работа с сетевыми ресурсами), они кардинально различаются по своей архитектуре, модели обработки данных и областям применения.

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

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

Кроме того, новый файловый API (NIO.2, представленный в Java 7) значительно расширил и упростил работу с файлами, предоставив разработчикам удобные методы для мониторинга изменений файловой системы (WatchService), а также эффективную и удобную работу с атрибутами файлов и директориями. Во многих случаях он позволяет отказаться от сторонних библиотек (например, Apache Commons IO) и использовать только возможности стандартной библиотеки Java.

В итоге, выбор между IO и NIO должен основываться на конкретных требованиях вашего приложения:

• Используйте Java IO, если для вас важны простота, удобство разработки, а также нет высоких требований к производительности и масштабированию.
• Выбирайте Java NIO, если вы работаете с высокими нагрузками, асинхронными операциями, большими файлами и стремитесь к максимальной эффективности и контролю над ресурсами.