Почему unowned работает быстрее weak и как это устроено на уровне runtime?

Почему unowned работает быстрее weak и как это устроено на уровне runtime?

• Swift, ARC, управление памятью
• unowned — неконтролируемая ссылка, которая не увеличивает счётчик ссылок
• weak — контролируемая ссылка: она изменяет счётчик и выполняет синхронизацию
• Для weak требуется атомарный доступ к хранимому объекту, включая проверку runtime на nil
• unowned не выполняет такую проверку, поэтому работает быстрее
• На уровне runtime unowned содержит только указатель и не использует дополнительные блоки
• weak работает через таблицу слабых ссылок и наблюдателей деалокации
• Практический вывод: unowned быстрее, но при ошибочном применении небезопасен и приводит к crash; weak надёжнее, однако работает медленнее из-за runtime overhead

Подробный ответ

Основной ответ

Unowned и weak — два варианта слабых ссылок в Swift и других языках, использующих ARC (automatic reference counting). Преимущество unowned по скорости связано с тем, что runtime не отслеживает изменения объекта и не проверяет nil при каждом обращении. Для weak такие проверки необходимы: ссылки хранятся как optional, а runtime должен убедиться, что они по-прежнему указывают на существующий объект, не допуская dangling pointers.

Ключевые моменты

• Unowned-ссылка имеет не-optional тип и предполагает, что объект существует в момент обращения. runtime не добавляет к такому обращению дополнительные проверки. Если объект уже удалён, попытка доступа вызывает аварийный сбой (crash), зато накладные расходы оказываются ниже.
• Weak-ссылка хранит объект в optional-виде (Optional<T>). Чтобы автоматически занулить weak-ссылки после деалокации объекта, runtime отслеживает его жизненный цикл. Для этого требуются дополнительная синхронизация и atomic операции с памятью.
• С точки зрения реализации weak-ссылки помещаются в специальную таблицу слабых ссылок runtime (weak table), связанную с каждым объектом, и там управляется их зануление. unowned в этой таблице не регистрируется: такая ссылка лишь хранит указатель на объект. Поэтому чтение и запись обходятся дешевле.

Практический контекст

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

Итак, выбор между unowned и weak — это баланс между безопасностью и производительностью: weak обеспечивает nil-сейф, а unowned представляет собой прямой указатель без проверок. В Swift 5+ реализация weak-ссылок была оптимизирована, однако при интенсивном использовании runtime overhead по-прежнему заметен.