RAII как философия управления ресурсами

Введение

Статьи 524, 532 и 547 неоднократно демонстрировали элементы RAII на конкретных примерах (умные указатели, классы-обёртки ресурсов) — в этой статье разберём RAII (Resource Acquisition Is Initialization) как целостную, общую философию управления ЛЮБЫМИ ресурсами в C++, а не только динамической памятью.

Концепция

RAII связывает приобретение любого ресурса (память, файловый дескриптор, сетевое соединение, мьютекс — основной цикл статей про многопоточность) с конструктором объекта-обёртки, а освобождение этого ресурса — с деструктором того же объекта, что гарантирует автоматическое, корректное освобождение ресурса при уничтожении объекта-обёртки, независимо от того, КАК происходит это уничтожение — обычный выход из области видимости (статья 525), досрочный return, или, что особенно ценно, раскрутка стека из-за исключения (статья 532/540). Это превращает управление ресурсами из ручной, подверженной ошибкам обязанности разработчика (явно вспоминать о необходимости освобождения в каждом возможном пути выхода из функции) в автоматическую, гарантированную самим механизмом языка операцию, существенно снижающую риск утечек ресурсов.

Пример кода: RAII как философия управления ресурсами

#include <iostream>
#include <mutex>

std::mutex resourceMutex;

void processWithoutRAII() // АНТИПАТТЕРН — ручное управление, подверженное ошибкам
{
    resourceMutex.lock();

    bool errorOccurred = true; // предположим, где-то возникла ошибка
    if (errorOccurred) {
        // ЗАБЫТО: resourceMutex.unlock(); — мьютекс останется ЗАБЛОКИРОВАННЫМ НАВСЕГДА!
        return;
    }

    resourceMutex.unlock();
}

void processWithRAII() // ПРАВИЛЬНО — RAII через std::lock_guard
{
    std::lock_guard<std::mutex> lock(resourceMutex); // блокировка мьютекса В КОНСТРУКТОРЕ

    bool errorOccurred = true;
    if (errorOccurred) {
        return; // lock АВТОМАТИЧЕСКИ разблокирует мьютекс в ДЕСТРУКТОРЕ при выходе из функции —
                  // НЕЗАВИСИМО от того, через какой именно return это произошло
    }
    // мьютекс автоматически разблокируется здесь тоже, при обычном завершении функции
}

// RAII для произвольного, не "встроенного" ресурса — собственный класс-обёртка
#include <iostream>

class ScopedTimer { // ресурс — "время начала измерения", а не память/мьютекс
public:
    ScopedTimer(const std::string &name) : m_name(name), m_start(std::chrono::steady_clock::now()) {}

    ~ScopedTimer()
    {
        auto end = std::chrono::steady_clock::now();
        auto duration = std::chrono::duration<double, std::milli>(end - m_start).count();
        std::cout << m_name << " заняло " << duration << " мс" << std::endl;
    }

private:
    std::string m_name;
    std::chrono::steady_clock::time_point m_start;
};

void measuredFunction()
{
    ScopedTimer timer("measuredFunction"); // создание объекта — НАЧАЛО измерения
    // ... любая работа функции, включая возможные исключения, ранние return ...
} // timer уничтожается ЗДЕСЬ — автоматический вывод измеренного времени, ГАРАНТИРОВАННО

Пояснения к коду

Сравнение processWithoutRAII()/processWithRAII() показывает суть проблемы и её решения — ручное управление мьютексом через явные lock()/unlock() требует не забыть вызвать unlock() на КАЖДОМ возможном пути выхода из функции (что становится экспоненциально сложнее для функций с множеством условных return, циклов с break, и потенциальных исключений), тогда как std::lock_guard (готовая, стандартная RAII-обёртка для мьютекса) гарантирует разблокировку автоматически, через свой деструктор, независимо от того, какой конкретный путь привёл к выходу из функции. ScopedTimer показывает, что RAII применим не только к «традиционным» ресурсам (память, мьютексы, файлы), но и к произвольным концепциям, для которых уместна модель «начало-конец действия» — измерение времени выполнения функции автоматически завершается (с гарантированным выводом результата) при выходе из функции, без необходимости вручную помещать код измерения и вывода результата на каждый возможный путь выхода из этой функции.

Подводные камни

Ручное управление ресурсами через явные пары «приобретение/освобождение» (lock/unlock, open/close, acquire/release) без оборачивания в RAII-класс, особенно в функциях с несколькими путями выхода или возможностью исключений — это та самая проблема, которую RAII решает архитектурно, и код, продолжающий использовать ручное управление там, где доступна или легко создаётся подходящая RAII-обёртка (стандартная, как std::lock_guard/std::unique_ptr, или собственная, написанная специально для конкретного ресурса), сознательно отказывается от значительного снижения риска утечек ресурсов, которое RAII предоставляет практически бесплатно.
Создание RAII-объекта без сохранения его в именованной переменной (например, std::lock_guard<std::mutex>(resourceMutex); без имени переменной) — без сохранения в переменную временный объект уничтожается немедленно, в конце этого же выражения (а не в конце блока, как ожидалось бы для реальной защиты критической секции кода), что полностью обесценивает предполагаемую защиту, и эта ошибка (хотя для некоторых случаев и предупреждаемая компилятором как «unused variable» или аналогичным предупреждением) может остаться незамеченной без внимательной проверки кода.
Передача владения ресурсом, управляемым RAII-объектом, способом, нарушающим гарантии RAII (например, извлечение «сырого» указателя/дескриптора из RAII-обёртки и попытка управлять им вручную, независимо от исходного RAII-объекта) — это создаёт риск ситуации, где и RAII-объект (при своём уничтожении), и код, вручную управляющий извлечённым ресурсом, попытаются освободить один и тот же ресурс, что является разновидностью двойного освобождения, аналогичной подводным камням статьи 547 про умные указатели.
Реализация деструктора RAII-класса, способного выбросить исключение при освобождении ресурса, без должного понимания критичности этого ограничения (статья 532/540) — RAII фундаментально полагается на надёжное, гарантированное выполнение деструктора для корректного освобождения ресурса даже в процессе раскрутки стека из-за уже происходящего исключения, и деструктор, сам способный выбросить исключение, нарушает эту фундаментальную надёжность, потенциально приводя к немедленному завершению программы через std::terminate(), если такое исключение возникает во время уже происходящей раскрутки стека из-за другого исключения.