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

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

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

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

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

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

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

Это особенно опасно для объектов, чей deinit освобождает внешний ресурс: файловый дескриптор, блокировку, временный файл или ресурс, переданный в системный либо C-интерфейс. Ошибка проявляется не как проблема подсчёта ссылок, а как неверное предположение о границе времени жизни.

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

ARC отслеживает сильные ссылки. Когда последняя сильная ссылка освобождена, объект немедленно становится недоступным для обычного использования, вызывается deinit, а затем память может быть освобождена.

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

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

final class Resource {
    deinit { print("resource closed") }
}

func use(_ resource: Resource) {
    withExtendedLifetime(resource) {
        print("operation uses the resource")
    }
}

После завершения замыкания объект всё ещё может жить, если существуют другие сильные ссылки. withExtendedLifetime не предотвращает циклы ссылок, не заменяет weak или unowned и не делает объект потокобезопасным.

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

Обёртка над системным ресурсом закрывает его в deinit. Функция передаёт ресурс в низкоуровневую операцию, но после последнего явного обращения к объекту выполняется вызов, которому ресурс всё ещё логически нужен. Ожидание, что локальная переменная автоматически продержит объект до конца функции, создаёт риск преждевременного закрытия ресурса.

Можно оставить обычную локальную ссылку, но это не даёт необходимой гарантии: оптимизатор вправе сократить её жизнь. Можно искусственно добавить обращение к объекту в конце функции, однако такой код хрупок и скрывает намерение. Выбранное решение — обернуть критическую операцию в withExtendedLifetime: зависимость явно видна, гарантия локальна, а лишнее продление времени жизни после операции не происходит.

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

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

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

Увеличивает ли withExtendedLifetime гарантированно счётчик ссылок на единицу?

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

Можно ли использовать deinit как точный сигнал завершения операции?

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