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

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

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

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

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

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

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

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

Когда внешняя ссылка на объект исчезает, объект всё ещё владеет callback, callback — захваченным хранилищем, а оно — объектом. В результате deinit не вызывается, а память и связанные ресурсы могут оставаться занятыми неопределённо долго.

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

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

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

final class Screen {
    var callback: (() -> Void)?

    func bind() {
        let owner = self
        callback = { owner.render() }
    }

    func render() {}
    deinit { print("deinit") }
}

После bind получается цепочка: Screen сильно удерживает callback, callback сильно удерживает owner, а owner указывает на тот же Screen. Текстовое отсутствие self в теле замыкания не означает отсутствия захвата владельца.

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

Слабый захват безопаснее, но требует обработать случай nil и имеет дополнительные runtime-издержки zeroing weak-ссылок. Явное обнуление callback освобождает цикл детерминированно, но требует корректно выбрать момент очистки и не гарантирует решение проблемы, если другие циклы существуют в графе владения.

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

Экран сохраняет обработчик события от дочернего компонента. При закрытии экрана deinit не вызывается. Проверка показывает цепочку: экран хранит обработчик, обработчик захватывает локальную переменную owner, а owner указывает на экран.

Вариант с сильным захватом прост, но создаёт цикл. Вариант с unowned устраняет сильное владение и не требует проверки nil, однако опасен, если компонент вызовет обработчик после уничтожения экрана. Вариант с weak допускает исчезновение экрана и позволяет безопасно пропустить обработку; для обычного callback закрываемого экрана это наиболее надёжное решение.

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

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

Разрывает ли цикл отсутствие явного self в тексте замыкания?

Нет. Важен не синтаксис обращения, а граф владения. Если замыкание захватывает локальную переменную, содержащую ссылку на объект, эта переменная может удерживать объект сильно независимо от того, называется ли она self, owner или иначе.

Поможет ли копирование ссылки в другую локальную переменную?

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

Достаточно ли заменить сильный захват на weak, не меняя остальную архитектуру?

Не всегда. Слабый захват устраняет конкретное владение замыкания объектом, но объект может продолжать удерживаться другими callback, задачами, подписками или контейнерами. После исправления нужно проверить весь граф владения и определить, что должно происходить при nil: пропуск события, отмена операции или явное освобождение подписки.