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

Захваченное локальное состояние сохраняется, потому что сохранённое escaping-замыкание владеет своим контекстом захвата. Этот контекст существует дольше вызова функции, пока существует само замыкание или другая ссылка на него.

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

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

Замыкания могут передаваться асинхронным операциям, сохраняться в свойствах и вызываться после возврата породившей их функции. Обычной жизни локальных переменных на стеке для этого недостаточно: после выхода из функции их окружение должно оставаться доступным.

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

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

Если функция передаёт замыкание наружу, локальные переменные не должны исчезнуть сразу после её завершения. Иначе callback потеряет захваченное состояние или обратится к уже недействительной памяти.

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

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

При создании escaping-замыкания Swift формирует контекст захвата. Сохранённое замыкание владеет этим контекстом, поэтому выход из функции не уничтожает захваченные значения.

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

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

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

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

Минимальный пример сильного захвата:

var saved: (() -> Void)?

final class Token {
    deinit { print("deinit") }
}

func prepare() {
    let token = Token()
    saved = { print(token) }
}

prepare()
// token всё ещё жив
saved = nil
// теперь контекст и token могут быть освобождены

После prepare() локальная переменная token вышла из области видимости, но объект продолжает жить благодаря сильному захвату замыканием. После присваивания saved = nil исчезает последняя ссылка на замыкание, поэтому его контекст и Token могут быть освобождены.

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

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

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

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

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

Всегда ли escaping-замыкание копирует значение локальной переменной в момент создания?

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

Нельзя делать универсальный вывод «замыкание всегда копирует текущее значение». Нужно учитывать тип значения, изменяемость переменной и наличие явного списка захвата.

Продлевает ли захват замыканием жизнь самой функции?

Нет. Функция завершается как обычно, а сохраняется только контекст захваченных данных. Локальные параметры и прочие данные, не попавшие в контекст, не становятся доступными после возврата функции.

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

Что произойдёт, если сохранить несколько копий одного escaping-замыкания?

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

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