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

std::weak_ptr не увеличивает счётчик сильных владельцев объекта. Поэтому взаимные ссылки, хранящиеся как weak_ptr, не препятствуют уничтожению объектов, когда исчезают все std::shared_ptr.

Объект временно получают через weak_ptr::lock(). Если объект ещё жив, метод возвращает shared_ptr; если объект уже уничтожен, возвращается пустой shared_ptr.

Исторический контекст

std::shared_ptr появился в C++11 как стандартный механизм совместного владения объектом с подсчёком ссылок. Такой подход автоматически освобождает объект после уничтожения последнего сильного владельца, но не может сам по себе корректно обработать цикл сильных ссылок.

Например, родитель может владеть ребёнком, а ребёнок — родителем. Даже после удаления внешних владельцев каждый объект продолжает удерживаться другим, поэтому счётчики не достигают нуля. std::weak_ptr был предусмотрен для ссылок, которым нужно наблюдать объект, но не продлевать его время жизни.

Постановка проблемы

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

Замена одной ссылки на weak_ptr устраняет владение, но вводит необходимость проверять, жив ли объект, непосредственно перед использованием. Нельзя безусловно получить ссылку или указатель на объект из weak_ptr, потому что объект мог быть уничтожен другим потоком или владельцем между операциями.

Подробное решение

shared_ptr и weak_ptr используют общий контрольный блок. В нём хранятся как минимум информация о сильных владельцах и слабых наблюдателях, а также механизм удаления управляемого объекта.

shared_ptr увеличивает счётчик сильных ссылок. Когда он становится нулевым, управляемый объект уничтожается. Контрольный блок может сохраниться дольше, пока существуют weak_ptr, поскольку им нужно безопасно определить состояние объекта и выполнить lock().

weak_ptr увеличивает только счётчик слабых ссылок и не влияет на время жизни объекта. Вызов lock() проверяет, существует ли сильный владелец, и при успехе создаёт shared_ptr, который временно гарантирует жизнь объекта на время работы с ним.

Минимальный пример разрыва цикла:

#include <memory>

struct Child;
struct Parent {
    std::shared_ptr<Child> child;
};
struct Child {
    std::weak_ptr<Parent> parent;
};

int main() {
    auto parent = std::make_shared<Parent>();
    auto child = std::make_shared<Child>();
    parent->child = child;
    child->parent = parent;
}

После выхода из main внешний shared_ptr на parent уничтожается, затем освобождается Parent. Сильная ссылка parent->child освобождает Child, а child->parent не удерживает Parent, потому что это weak_ptr.

Основное ограничение — weak_ptr нельзя разыменовать напрямую. Сначала нужно вызвать lock() и проверить результат. В многопоточном коде следует сохранять возвращённый shared_ptr в локальную переменную: он удерживает объект живым до конца операции, даже если другие владельцы одновременно исчезают.

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

Ситуация из практики

В GUI-модели окно владеет дочерними виджетами, а виджет должен обращаться к окну для отправки событий. Вариант с shared_ptr в обе стороны создаёт цикл: закрытие окна удаляет внешний владелец, но окно и виджеты продолжают удерживать друг друга.

Можно было бы использовать сырые указатели. Это устраняет цикл, но не выражает явно отсутствие владения и создаёт риск обращения к уже уничтоженному окну.

Выбранное решение — хранить дочерние виджеты в shared_ptr внутри окна, а обратную ссылку виджета на окно — в weak_ptr. При обработке события виджет вызывает lock(), проверяет полученный shared_ptr и работает с окном только при успешном получении владельца.

В результате время жизни модели управляется автоматически, цикл отсутствует, а обращение к уничтоженному окну не происходит. Цена решения — дополнительная проверка результата lock() и необходимость ясно документировать, какие связи владеют объектами, а какие только наблюдают их.

Что кандидаты часто упускают

Почему нельзя просто вызвать expired(), а затем использовать результат lock()?

expired() лишь сообщает состояние в момент проверки. В многопоточном коде объект может быть уничтожен сразу после этого вызова, поэтому такая проверка сама по себе не защищает от гонки и обычно бесполезна как предварительное условие.

Надёжный вариант — сразу вызвать lock() и проверить возвращённый shared_ptr. Полученный сильный владелец атомарно фиксирует объект живым на время дальнейшей работы.

Почему контрольный блок может жить после уничтожения управляемого объекта?

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

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

Всегда ли weak_ptr нужен для обратной ссылки?

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

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