Ответ на вопрос
Swift реализует оператор defer через стек замыканий, создаваемый компилятором, который прикрепляется к каждой лексической области видимости. Когда компилятор встречает блок defer, он извлекает код в замыкание и регистрирует его в записи очистки текущей области. При выходе из области видимости — независимо от того, происходит ли он через нормальный поток, return, throw или break — среда выполнения выполняет эти замыкания в порядке Last-In-First-Out (LIFO). Эта дисциплина стека гарантирует, что ресурсы, приобретенные позже, освобождаются первыми, сохраняя цепочки зависимостей без ручного учета.
История вопроса
Очистка ресурсов исторически полагалась на детерминированные деструкторы или многословную обработку исключений. C++ связывает очистку с временем жизни объектов через RAII, в то время как Java и C# требуют явных блоков try-finally, которые отделяют логику очистки от кода получения. Go представил оператор defer для предоставления очистки на основе области без объектно-ориентированных накладных расходов, что повлияло на дизайн Swift. Swift принял defer в версии 2.0, чтобы дополнить свою модель обработки ошибок, предлагая декларативную альтернативу finally, которая интегрируется с операторами guard и ранними возвратами.
Проблема
Сложные функции с несколькими путями выхода — такие как операции с файлами, аутентификацией, ведением журналов и сетевой передачей — требуют тщательного управления ресурсами. Разработчики должны обеспечивать, чтобы каждое место return или throw освобождало все ранее приобретенные ресурсы, от дескрипторов файлов до закладок с безопасной областью. Пропуск одной точки очистки ведет к утечкам или взаимным блокировкам, в то время как неправильный порядок (закрытие базы данных перед сбросом ее журнала транзакций) вызывает порчу данных. Ручная очистка становится непрактичной по мере увеличения сложности функции, создавая потребность в автоматической, детерминированной и упорядоченной утилизации ресурсов, связанной с границами области видимости.
Решение
Компилятор Swift преобразует операторы defer в стек указателей на функции, хранящихся в записи активации охватывающей области. Каждый оператор defer помещает свое замыкание в этот управляемый компилятором стек во время выполнения. Когда поток управления достигает закрывающей фигурной скобки области или сталкивается с оператором выхода, вставленный код эпилога проходит по стеку в обратном порядке и выполняет каждое замыкание. Этот механизм интегрируется с обработкой ошибок в Swift, гарантируя, что все ожидающие блоки defer выполняются до того, как ошибка распространится на внешнюю область catch, обеспечивая очистку независимо от пути выхода.
Ситуация из жизни
Рассмотрим приложение iOS, экспортирующее зашифрованные данные пользователя. Процесс получает URL ресурса с безопасной областью, открывает FileHandle, записывает зашифрованные байты и загружает результат. Каждый шаг может завершиться неудачей и требует строгой очистки, чтобы избежать утечек дескрипторов файлов или постоянных закладок ресурсов.
Решение 1: Ручная очистка в каждой точке выхода.
Разработчики могут дублировать fileHandle.close() и url.stopAccessingSecurityScopedResource() перед каждым return или throw. Этот подход хрупкий; добавление новой проверки на ошибку требует обновления нескольких мест, и рецензенты должны подтверждать, что порядок очистки соответствует порядку приобретения. Риск утечек увеличивается с каждой новой точкой выхода, добавленной во время обслуживания.
Решение 2: Объекты-обертки с deinit.
Создание класса ScopeManager, который выполняет очистку в своем deinit, полагается на ARC. Тем не менее, ARC не гарантирует немедленное освобождение при выходе из области видимости; объекты могут существовать до тех пор, пока не исчерпается пул автососложения или переменная не будет перезаписана. В длинных циклах это задерживает освобождение ресурсов, вызывая системные ошибки "слишком много открытых файлов", которые трудно воспроизвести.
Решение 3: Блоки defer.
Команда объявила блоки defer сразу после получения каждого ресурса:
func exportData() throws { let url = try acquireResource() defer { url.stopAccessingSecurityScopedResource() } let fileHandle = try FileHandle(forWritingTo: url) defer { fileHandle.close() } let encrypted = try encrypt(data) try fileHandle.write(encrypted) try upload(fileHandle) }
Когда ошибка шифрования вызвала throw, среда выполнения автоматически закрыла дескриптор файла, а затем прекратила доступ к ресурсу, сохраняя правильный обратный порядок. Это решение было выбрано за его детерминированность и локальность — код очистки появляется рядом с кодом получения.
Результат:
Функция экспорта прошла стресс-тестирование с 10,000 параллельных операций без утечек дескрипторов файлов. Кодовый обзор не выявил пропущенных путей очистки, а профилирование показало немедленное освобождение ресурсов по сравнению с подходом deinit.
Что кандидаты часто упускают
Вопрос 1: Выполняется ли блок defer, если функция завершает работу через fatalError или бесконечный цикл?
Нет. defer выполняется только когда поток управления достигает конца своей охватывающей области. Если вызывается fatalError, процесс завершается немедленно без разворачивания областей или выполнения блоков очистки. Аналогично, бесконечный цикл while предотвращает выход из области видимости; блоки defer внутри тела цикла выполняются только тогда, когда итерация завершается, но цикл while true на уровне функции никогда не вызывает блоки defer на уровне функции.
Вопрос 2: Как defer обрабатывает захват переменной, когда переменная изменяется после объявления defer?
defer по умолчанию захватывает переменные по ссылке, а не по значению. Например:
var count = 0 defer { print("Deferred: \(count)") } count = 5 // Печатает 5, а не 0
Чтобы захватить значение на момент объявления, разработчики должны использовать явный список захвата: defer { [value = currentValue] in ... }. Кандидаты часто предполагают, что defer захватывает снимок во время времени объявления, что приводит к логическим ошибкам в циклах или мутирующих алгоритмах.
Вопрос 3: Каков порядок выполнения, когда блоки defer вложены внутри условных ветвлений по сравнению с родительской областью?
Блоки defer связаны с лексической областью, в которой они появляются, а не с областью функции. Блок defer внутри блока if выполняется, когда этот блок if выходит, а не когда функция возвращает. Если существуют несколько блоков defer на разных уровнях вложенности, блок defer самой внутренней области выполняется первым при выходе из этого конкретного блока. Это приводит к неинтуитивному порядку, когда разработчики ожидают, что все блоки defer будут выполняться при выходе из функции, особенно при перемешивании defer с операторами guard, которые создают ранние выходы из под-областей.