Может ли создаться Side Table если есть одна Strong и одна Unowned ссылка?

Анализ взаимосвязи Strong/Unowned ссылок и Side Tables

Чтобы дать точный ответ, нужно сначала разобраться, что такое Side Table (вспомогательная таблица) в контексте управления памятью Swift и когда она создается.

Что такое Side Table?

Side Table — это дополнительный, отдельно размещенный в куче объект, который содержит дополнительные метаданные об экземпляре класса, когда это необходимо. Основная цель — поддерживать механизмы слабых (weak) и невладеющих (unowned) ссылок, а также счетчик дополнительных сильных ссылок при использовании unowned(unsafe) или для внутренней оптимизации.

Ключевая информация, которая обычно хранится в Side Table:

• Счетчик слабых ссылок (weak reference count).
• Счетчик ссылок на саму Side Table (strong side table reference count).
• Указатель на основной объект (inline reference count и сам объект находятся в основной выделенной памяти).

Когда создается Side Table?

Согласно документации Swift Runtime и исходному коду, Side Table создается не сразу при создании объекта, а лениво (lazily), когда в этом возникает необходимость. А именно:

1. Когда создается первая слабая (weak) ссылка на объект.
2. Когда объект начинает уничтожаться (счетчик сильных ссылок достигает нуля), но остались живые невладеющие (unowned) ссылки. В этот момент Side Table используется для отслеживания состояния объекта ("разрушен, но память еще не освобождена").

Ответ на вопрос

Нет, одна сильная (strong) и одна невладеющая (unowned) ссылка НЕ приведут к немедленному созданию Side Table.

Объяснение по шагам:

1. Инициализация объекта:

   class MyClass {}
   var strongRef: MyClass? = MyClass() // Объект создан. Сильных ссылок = 1.
   

    В этот момент в памяти есть только объект с его **встроенным (inline) счетчиком ссылок**. Side Table отсутствует.

1. Создание unowned ссылки:

   unowned let unownedRef = strongRef! // unownedRef указывает на тот же объект.
   

    `unowned` ссылка — это, по сути, **сырой указатель** с гарантией времени жизни со стороны разработчика. Она **не участвует** в подсчете ссылок. Runtime на данном этапе **не нуждается** в дополнительных метаданных, чтобы отслеживать эту ссылку. Поэтому Side Table все еще **не создается**.

1. Поведение при освобождении сильной ссылки:

   strongRef = nil // Сильных ссылок становится 0.
   

    Теперь сильных ссылок на объект нет. Поскольку существует живая `unowned` ссылка (`unownedRef`), объект **не может быть немедленно деинициализирован и освобожден из памяти**. В этот критический момент Runtime **создает Side Table** (если он еще не был создан) или использует уже существующий. Объект переходит в состояние **"разрушен" (deinitted but not deallocated)**:
    *   Память объекта пока не переиспользуется.
    *   `unownedRef` все еще указывает на эту область памяти.
    *   Side Table хранит информацию о том, что объект разрушен.

1. Попытка доступа через unowned:

   print(unownedRef) // ❌ Runtime ошибка! Объект уже деинициализирован.
   

    При попытке доступа Runtime проверяет состояние объекта через Side Table, видит, что объект разрушен, и **траппится (аварийно завершает выполнение)**. Это гарантирует безопасность, в отличие от `unowned(unsafe)`.

Ключевые выводы

• Триггер создания — Основными триггерами для создания Side Table являются операции со слабыми (weak) ссылками и момент перехода объекта в разрушенное состояние при наличии unowned ссылок.
• Unowned vs Weak — unowned ссылка, в отличие от weak, не требует немедленного создания Side Table, так как она не обнуляется автоматически. Ей нужны метаданные Side Table только на этапе, когда объект уже разрушен, но память еще не освобождена, чтобы обеспечить проверку при доступе.
• Пример с Weak для контраста:

  class MyClass {}
  var strongRef: MyClass? = MyClass()
  weak var weakRef = strongRef // ✅ В ЭТОТ момент с высокой вероятностью создается Side Table!
  

    Здесь Side Table нужен сразу, чтобы хранить счетчик слабых ссылок и обеспечить механизм обнуления `weakRef` в `nil` при деинициализации объекта.

Итог: В сценарии с одной strong и одной unowned ссылкой Side Table будет создан не в момент создания ссылок, а лениво, в момент обнуления сильной ссылки, чтобы управлять состоянием разрушенного объекта и обеспечивать безопасность доступа через unowned.