> Как избежать утечек памяти при работе с файлами в цикле в Go (Go)

Короткий ответ

Утечки памяти при работе с файлами в цикле в Go возникают из-за незакрытых файловых дескрипторов, накопления данных в слайсах или строках, а также из-за захвата переменных замыканиями. Основные меры: всегда закрывать файл через defer внутри отдельной функции или сразу после чтения, использовать io.Reader с ограничением размера, избегать глобальных накопительных структур, следить за областью видимости переменных в цикле. В Go сборщик мусора не управляет файловыми дескрипторами - их нужно закрывать явно.

Подробное объяснение

Утечки памяти в Go при работе с файлами в цикле бывают трёх типов:

1. Утечка файловых дескрипторов - самый частый случай. Каждый вызов os.Open или os.Create занимает дескриптор в ОС. Если файл не закрыт, дескрипторы копятся, пока процесс не упрётся в лимит (ulimit -n). Go не имеет финализаторов для файлов - только явный Close().

2. Накопление данных в памяти - если в цикле читать файлы в слайс или строку без ограничения размера, память растёт. Особенно опасно при чтении больших файлов целиком через ioutil.ReadFile внутри цикла.

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

Ключевой момент: defer в цикле не срабатывает до конца функции. Если писать:

GO
for _, file := range files {
    f, _ := os.Open(file)
    defer f.Close() // сработает только в конце всей функции!
}

то все дескрипторы будут открыты до конца функции. Правильно - выносить работу с файлом в отдельную функцию или закрывать явно.

На практике

Для senior-позиции важно не просто закрывать файлы, а понимать паттерны:

• Функциональная изоляция: каждая операция с файлом - в отдельной функции, где defer срабатывает сразу после выхода.
• Ограничение размера чтения: использовать io.LimitReader или читать порциями через bufio.Scanner с заданным буфером.
• Потоковая обработка: не накапливать данные, а обрабатывать каждую строку/чанк сразу.
• Проверка ошибок: Close() тоже может вернуть ошибку, её нужно обрабатывать, особенно при записи.
• Использование defer с анонимной функцией для логирования ошибок закрытия.

Также стоит упомянуть про sync.Pool для переиспользования буферов, если файлов много и они читаются порциями - это снижает нагрузку на GC.

Пример кода

Плохой вариант - утечка дескрипторов:

GO
func processFiles(files []string) error {
    for _, name := range files {
        f, err := os.Open(name)
        if err != nil {
            return err
        }
        // defer f.Close() здесь - ошибка, сработает в конце функции
        data, _ := io.ReadAll(f)
        process(data)
    }
    return nil
}

Хороший вариант - изоляция в отдельной функции:

GO
func processFile(name string) error {
    f, err := os.Open(name)
    if err != nil {
        return err
    }
    defer func() {
        if cerr := f.Close(); cerr != nil {
            log.Printf("close %s: %v", name, cerr)
        }
    }()

    scanner := bufio.NewScanner(f)
    scanner.Buffer(make([]byte, 64*1024), 1024*1024) // ограничение размера строки
    for scanner.Scan() {
        processLine(scanner.Bytes()) // не храним данные после обработки
    }
    return scanner.Err()
}

func processFiles(files []string) error {
    for _, name := range files {
        if err := processFile(name); err != nil {
            return err
        }
    }
    return nil
}

Вариант с ограничением чтения для больших файлов:

GO
func readFirstBytes(name string, limit int64) ([]byte, error) {
    f, err := os.Open(name)
    if err != nil {
        return nil, err
    }
    defer f.Close()

    return io.ReadAll(io.LimitReader(f, limit))
}

Как отвечать на собеседовании

Начните с главной причины - файловые дескрипторы не управляются GC. Затем покажите понимание defer в цикле и объясните, почему нужна изоляция. Приведите пример с bufio.Scanner и ограничением буфера. Упомяните обработку ошибок при Close(), особенно для записи - это показывает внимание к деталям. Если спросят про горутины - скажите, что при параллельной обработке файлов нужно использовать errgroup с ограничением конкурентности и передавать имя файла как параметр, а не захватывать переменную цикла.

Что проверяет интервьюер

• Понимание разницы между памятью heap и файловыми дескрипторами.
• Знание семантики defer в циклах.
• Умение проектировать код с функциональной изоляцией.
• Осознание trade-off между чтением целиком и потоковой обработкой.
• Внимание к обработке ошибок при закрытии файлов.
• Понимание ограничений bufio.Scanner (максимальный размер токена).

Типичные ошибки

• Использование defer внутри цикла без выноса в отдельную функцию.
• Чтение файлов целиком через os.ReadFile в цикле без ограничения размера.
• Игнорирование ошибки от Close().
• Накопление строк в слайсе для последующей обработки вместо потоковой.
• Захват переменной цикла в замыкании при запуске горутин (в Go до 1.22 это была классическая ошибка).
• Забывание про scanner.Buffer() для больших строк - по умолчанию лимит 64KB, и Scan() вернёт ошибку.