Верно ли, что каждая сильная ссылка в Swift увеличивает доступный счётчик ссылок объекта ровно на единицу?
Нет. Сильные ссылки создают владение объектом на уровне семантики Swift, но это не означает существование одного публичного целочисленного счётчика, где каждой ссылке соответствует ровно одна единица. ARC может оптимизировать операции удержания и освобождения, поэтому по внутреннему счётчику или трассировке retain/release нельзя надёжно восстановить число сильных ссылок.
ARC появился как способ автоматизировать ручное управление временем жизни объектов, при котором разработчик явно вызывал операции удержания и освобождения. Подход сохраняет детерминированное освобождение при исчезновении последнего владения, но переносит расстановку нужных операций на компилятор и runtime.
В отличие от трассирующего сборщика мусора, ARC не ищет все недостижимые объекты. Он отслеживает владение ссылками, однако конкретная реализация этого отслеживания не является частью модели, доступной прикладному коду.
Разработчик видит несколько переменных, свойств или захватов объекта и пытается вывести его время жизни по предполагаемому числу увеличений счётчика. Такая логика ненадёжна: компилятор может устранить избыточное удержание, объединить операции или временно продлить жизнь объекта для корректности вызова.
Ошибочный вывод особенно опасен при диагностике преждевременного deinit, retain cycle или поведения в многопоточном коде. Программа должна опираться на правила владения, а не на конкретные внутренние значения счётчика.
На уровне языка сильная ссылка означает: пока это владение действительно, объект не может быть уничтожен ARC. Когда последнее необходимое сильное владение исчезает, экземпляр становится доступным для уничтожения, после чего выполняется deinit и освобождаются его ресурсы.
Но компилятор видит всю область применения ссылок и может оптимизировать управление временем жизни. Например, отдельное увеличение счётчика может быть не нужно, если вызываемый код гарантированно не переживёт текущую операцию; несколько удержаний могут быть сведены к более эффективной последовательности. Поэтому физические операции retain/release не обязаны совпадать один к одному с синтаксическими присваиваниями и переменными.
Кроме того, runtime может использовать разные внутренние механизмы хранения информации о владении. Детали счётчиков, побочных таблиц и оптимизированных состояний являются реализационными и не должны использоваться как API или как способ синхронизации.
Практический критерий такой: сильная ссылка удерживает объект, weak-ссылка не удерживает, unowned-ссылка не удерживает и требует гарантии времени жизни. Если нужно сделать жизнь объекта гарантированной на конкретном участке, следует выразить это через сильное владение или withExtendedLifetime, а не пытаться искусственно влиять на счётчик.
Во время расследования разработчик замечает, что количество операций retain в трассировке отличается от числа присваиваний объекта в сильные переменные. Он делает вывод, что ARC «теряет» ссылку, и добавляет ручные удержания.
Вариант с ручным вмешательством плох: он нарушает модель ARC, может создать утечку или скрыть настоящую ошибку в графе владения. Вариант с анализом только трассировки тоже ограничен: оптимизации компилятора меняют наблюдаемую последовательность операций.
Корректное решение — проверить, какие ссылки должны владеть объектом на уровне дизайна, найти реальные циклы или преждевременное обнуление weak-ссылок и использовать инструменты профилирования памяти для подтверждения результата. Такой подход отделяет гарантии языка от деталей конкретной сборки и позволяет устранить причину, а не подгонять код под внутренний счётчик.
Нет. Эти операции могут быть удалены, объединены или появляться из-за временных соглашений вызова. Логи полезны для поиска направления удержания, но не дают переносимой модели «одна операция — одна ссылка».
Не обязательно. Семантически Swift должен сохранить объект до последнего необходимого использования, но компилятор может определить, что дальнейшее значение переменной уже не используется. Если требуется гарантировать жизнь объекта до конкретной точки, применяют явное средство вроде withExtendedLifetime.
Для корректно реализованного ARC объект не уничтожается, пока существует необходимое сильное владение. Однако числовое представление внутреннего состояния не обязано буквально отражать число ссылок и может иметь служебные или оптимизированные состояния. Поэтому сравнивать условное значение счётчика с моментом deinit некорректно; важен граф владения и соблюдение правил доступа.