C/C++ Ready | Программирование

Почему захват [this] в асинхронном коде опасен?

Многие воспринимают [this] как безопасный способ вызвать метод объекта позже. Но на самом деле лямбда сохраняет только указатель this. Она не продлевает время жизни объекта.

Если задача выполнится уже после уничтожения Session, лямбда попробует обратиться к несуществующему объекту. В лучшем случае это закончится падением, в худшем — редким и трудноуловимым UB.

Проблема в том, что код выглядит абсолютно нормально. Пока объект жив, все работает. Но как только lifetime объекта и lifetime задачи расходятся, появляется use-after-free.

Например, опасный сценарий выглядит так:

void run(ThreadPool& pool) {
    Session s;
    s.start(pool);
} // s уже уничтожен, а задача может выполниться позже

Еще хуже, когда внутри лямбды идет доступ к полям объекта:

class Session {
    std::string buffer;

public:
    void start(ThreadPool& pool) {
        pool.post([this] {
            std::cout << buffer << "\n"; // доступ к уже мертвому объекту
        });
    }
};

Если объект должен пережить асинхронный вызов, его временем жизни нужно управлять явно. Обычно для этого используют shared_ptr и weak_ptr.

class Session : public std::enable_shared_from_this<Session> {
public:
    void start(ThreadPool& pool) {
        auto weak = weak_from_this();
        pool.post([weak] {
            if (auto self = weak.lock()) {
                self->flush();
            }
        });
    }

    void flush();
};

Такой код сначала проверяет, жив ли объект вообще, и только потом вызывает метод.

Иногда используют и более прямой вариант с shared_from_this(), когда задаче нужно гарантированно удерживать объект живым до конца выполнения:

void start(ThreadPool& pool) {
    auto self = shared_from_this();
    pool.post([self] {
        self->flush();
    });
}

🔥 Захват [this] не делает асинхронный код безопасным. Если время жизни объекта не контролируется, это прямой путь к use-after-free.

📣 C++ Ready | #совет

Please open Telegram to view this post