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

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

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

ARC автоматизировал управление сильными ссылками, но не устранил циклы владения: два объекта могут навсегда удерживать друг друга. Для ссылок, которые должны наблюдать за объектом, не владея им, используются weak и unowned.

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

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

Сама weak-ссылка не препятствует деалокации объекта. Поэтому последовательность «проверить weak-ссылку, затем отдельно прочитать её и вызвать метод» может быть некорректной: между двумя чтениями объект способен исчезнуть.

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

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

При чтении weak Swift пытается получить текущий объект. Если объект существует, результат чтения становится обычной сильной ссылкой, например локальной константой после if let. Эта сильная ссылка увеличивает число сильных владельцев либо эквивалентно удерживает объект согласно внутренней реализации ARC, поэтому объект не может быть уничтожен до окончания использования локальной ссылки.

final class Service {
    func start() {}
}

weak var service: Service?

if let service {
    service.start()
}

В этом примере service внутри блока — сильная локальная ссылка. Она была получена одним чтением weak-ссылки и сохраняет объект живым во время вызова start().

Важно отличать это от продления жизни самой слабой ссылкой. После выхода из блока сильная локальная ссылка исчезает, а weak-ссылка по-прежнему не владеет объектом. Если других сильных владельцев нет, объект может быть уничтожен, а слабая ссылка станет nil.

Конструкция if weakReference != nil { weakReference!.start() } хуже: проверка и последующее извлечение выполняют два отдельных чтения. Без гарантии внешней синхронизации между ними состояние объекта может измениться. Даже в однопоточном коде такая запись менее ясна; предпочтителен if let или guard let, который сразу создаёт сильную локальную ссылку.

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

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

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

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

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

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

Увеличивает ли чтение weak счётчик сильных ссылок навсегда?

Нет. Сильным становится только результат конкретного чтения — например локальная переменная внутри if let. После выхода этой переменной из области действия объект больше не удерживается этим чтением, а исходная weak-ссылка остаётся невладеющей.

Почему проверка weak-ссылки и её последующее использование неравноценны if let?

Проверка вроде weakReference != nil лишь сообщает состояние на момент первого чтения. Повторное обращение может произойти позже, когда объект уже уничтожен. if let object = weakReference выполняет одно чтение и сохраняет успешный результат как сильную ссылку, поэтому object остаётся доступным в пределах соответствующего блока.

Защищает ли weak от гонок между потоками?

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