Розбиття великих файлів на чанки

1. Чому читати великі файли в один потік — це як носити цеглини по одній

Коли ви працюєте з великими файлами — десятки чи сотні мегабайт, а то й гігабайти — однопотокове читання або запис швидко перетворюються на вузьке місце. Один потік просто не справляється з навантаженням: диск може віддавати дані швидше, ніж програма встигає їх обробляти.

Навіть якщо у вас швидкий SSD, потік упреться не в диск, а в накладні витрати — перемикання контексту, роботу з буферами, перетворення даних у пам’яті. У підсумку продуктивність падає, а процесор при цьому простоює, адже інші його ядра бездіяльні.

Припустімо, ви вирішили порахувати кількість слів у величезному журналі. Якщо робити це послідовно, один потік монотонно «гризтиме» файл, а ви — просто чекатимете. А якщо розбити файл на частини й доручити обробку кільком потокам, справа піде значно швидше: кожен обробляє свою частину, і в результаті ви майже повністю використовуєте потенціал диска.

На практиці це виглядає так: на SSD із пропускною здатністю 2 ГБ/с однопотокове читання дає лише близько 300–500 МБ/с. А якщо читати паралельно — можна вичавити з накопичувача усе, на що він здатен.

2. Chunking — як змусити файл працювати на вас

Коли файл стає надто великим, щоб обробити його цілком, найрозумніше — розбити його на частини. Цей прийом називається chunking (від слова chunk — «шматок»). Ідея проста: ви ділите великий файл на кілька логічних сегментів і доручаєте кожному потоку свою ділянку.

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

Такий підхід дає змогу задіяти всі ядра процесора одночасно й помітно прискорює обробку, особливо якщо у вас сучасний SSD або NVMe-диск. У задачах на кшталт підрахунку рядків, пошуку за текстом чи агрегації статистики chunking працює як турбонаддув — просто додає швидкості без особливих зусиль.

Як підібрати розмір чанка

Розмір чанка — це майже як розмір порції їжі: надто маленька — намучитеся нарізати, надто велика — важко перетравити. Усе залежить від задачі та можливостей вашої машини.

У середньому добрі результати дає робота в діапазоні 8–64 МБ на потік. Для більшості задач достатньо взяти щось близько 10–20 МБ, але ідеального числа немає — усе підбирається експериментально. Головне — щоб шматок був досить великим, аби не втрачати час на зайві перемикання потоків, і не настільки великим, щоб перевантажувати кеш‑пам’ять процесора або займати всю пам’ять.

Якщо ви працюєте з текстами — наприклад, рахуєте слова або шукаєте збіги — важливо, щоб чанки не «рвали» рядки чи слова посередині. Зазвичай це вирішують просто: роблять невелике перекриття між частинами або зсувають межі до найближчого символу нового рядка. Так обробка залишиться точною, а результат — чистим і передбачуваним.

3. Інструменти для позиційного доступу: FileChannel і MappedByteBuffer

FileChannel: позиційний I/O

FileChannel — це клас із пакета java.nio.channels, який дозволяє працювати з файлами на низькому рівні, зокрема читати й писати дані з/у довільну позицію файлу.

Ключові методи:

• position(long newPosition) — встановити позицію (offset) для читання/запису.
• read(ByteBuffer dst, long position) — прочитати дані з файлу в буфер, починаючи з вказаної позиції (не змінює поточну позицію каналу!).
• write(ByteBuffer src, long position) — записати дані у файл з вказаної позиції.

Приклад: читання шматка файлу

try (FileChannel channel = FileChannel.open(Path.of("bigfile.txt"), StandardOpenOption.READ)) {
    long chunkSize = 16 * 1024 * 1024; // 16 МБ
    long offset = 0;
    ByteBuffer buffer = ByteBuffer.allocate((int) chunkSize);
    int bytesRead = channel.read(buffer, offset);
    // buffer містить перші 16 МБ файлу
}

Переваги:

• Можна читати/писати з будь-якої позиції.
• Зручно для паралельної обробки: кожен потік працює зі своїм шматком.

MappedByteBuffer: memory-mapped files

MappedByteBuffer — це спеціальний буфер, який дозволяє «відобразити» (map) частину файлу в пам’ять. Операційна система сама дбає про завантаження даних із диска в пам’ять і назад.

Як це працює?

• Ви відображаєте шматок файлу в пам’ять.
• Читаєте й пишете в буфер — ОС сама підвантажує потрібні сторінки.
• Немає явних викликів read/write — усе відбувається через пам’ять.

Приклад:

try (FileChannel channel = FileChannel.open(Path.of("bigfile.txt"), StandardOpenOption.READ)) {
    long chunkSize = 16 * 1024 * 1024; // 16 МБ
    long offset = 0;
    MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, offset, chunkSize);
    // Тепер buffer поводиться як масив байтів, але дані зчитуються з диска в міру звернення
}

Плюси:

• Дуже висока швидкість (особливо на SSD).
• Простота: читаєш/пишеш як у масив.

Мінуси:

• Використовує віртуальну пам’ять — якщо файл дуже великий, можна заповнити пам’ять.
• Керувати вивантаженням з пам’яті складно (буфер може триматися в пам’яті довше, ніж потрібно).
• Не завжди зручно для дуже великих файлів (понад 2–4 ГБ на 32-бітних системах).

4. Приклад: паралельне читання і підрахунок слів

Розглянемо задачу: порахувати кількість слів у великому текстовому файлі (наприклад, у журналі розміром 10 ГБ) за допомогою паралельної обробки.

Крок 1. Розбиваємо файл на чанки

• Отримуємо розмір файлу: long fileSize = Files.size(path);
• Обираємо розмір чанка, наприклад, 16 МБ.
• Для кожного чанка обчислюємо зміщення: offset = chunkIndex * chunkSize;
• Останній чанк може бути меншим за розміром.

Крок 2. Створюємо задачі для потоків

• Для кожного чанка створюємо Callable<Integer> (або Runnable), який:
  • Відкриває свій шматок файлу через FileChannel.read(ByteBuffer, offset) або MappedByteBuffer.
  • Рахує кількість слів у своєму шматку.
  • Повертає результат (кількість слів).

Крок 3. Запускаємо задачі через ExecutorService

• Створюємо пул потоків: ExecutorService pool = Executors.newFixedThreadPool(N);
• Відправляємо задачі у пул: List<Future<Integer>> results = pool.invokeAll(tasks);
• Збираємо результати: підсумовуємо значення з усіх future.

Приклад коду (спрощено):

import java.nio.*;
import java.nio.channels.*;
import java.nio.file.*;
import java.util.*;
import java.util.concurrent.*;

public class ParallelWordCount {
    public static void main(String[] args) throws Exception {
        Path path = Path.of("bigfile.txt");
        long fileSize = Files.size(path);
        int chunkSize = 16 * 1024 * 1024; // 16 МБ
        int chunks = (int) ((fileSize + chunkSize - 1) / chunkSize);

        ExecutorService pool = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
        List<Future<Integer>> results = new ArrayList<>();

        for (int i = 0; i < chunks; i++) {
            long offset = (long) i * chunkSize;
            long size = Math.min(chunkSize, fileSize - offset);

            results.add(pool.submit(() -> {
                try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
                    MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_ONLY, offset, size);
                    byte[] bytes = new byte[(int) size];
                    buffer.get(bytes);
                    String text = new String(bytes);
                    // Важливо: опрацювати межі чанка, щоб не розірвати слово!
                    return countWords(text);
                }
            }));
        }

        int totalWords = 0;
        for (Future<Integer> f : results) {
            totalWords += f.get();
        }
        pool.shutdown();
        System.out.println("Total words: " + totalWords);
    }

    private static int countWords(String text) {
        // Найпростіший спосіб: розбити за пробілами і відфільтрувати порожні рядки
        String[] words = text.split("\\s+");
        int count = 0;
        for (String w : words) {
            if (!w.isBlank()) count++;
        }
        return count;
    }
}

Увага: у реальних задачах потрібно акуратно обробляти межі чанків, щоб не розірвати слово або рядок між двома потоками. Зазвичай роблять невеликий overlap (наприклад, +100 байт) і коригують початок/кінець чанка.

5. Підсумки та найкращі практики

• Для великих файлів використовуйте розбиття на чанки і паралельну обробку.
• Застосовуйте FileChannel для позиційного доступу, а MappedByteBuffer — для memory-mapped файлів.
• Розмір чанка підбирайте експериментально; орієнтир — кеш‑пам’ять процесора та пропускна здатність диска.
• Акуратно обробляйте межі чанків (особливо для текстів).
• Для паралельної обробки використовуйте ExecutorService і пул потоків.
• Не зловживайте кількістю потоків: зазвичай достатньо 2–4 потоків на SSD.
• Стежте за споживанням пам’яті: MappedByteBuffer може зайняти багато віртуальної пам’яті.

6. Типові помилки під час роботи з великими файлами та chunking

Помилка №1: Зчитування всього файлу в пам’ять. Під час обробки великих файлів це може призвести до OutOfMemoryError. Натомість читайте дані частинами (чанками).

Помилка №2: Некоректна обробка меж чанків. Якщо різати файл без урахування меж рядків або слів, можна «розірвати» дані, і підсумок буде некоректним.

Помилка №3: Неоптимальний розмір чанка. Надто маленькі чанки створюють зайві накладні витрати на керування потоками, а надто великі — неефективно використовують пам’ять.

Помилка №4: Незакритий FileChannel. Це призводить до витоків ресурсів. Використовуйте try-with-resources, щоб гарантувати закриття каналу.

Помилка №5: Надмірна кількість потоків. Якщо потоків занадто багато, диск не встигає обслуговувати запити, і продуктивність падає замість зростання.