Можно ли считать weak-ссылку гарантированно ненулевой внутри deinit объекта?
Нет. Внутри deinit нельзя полагаться на то, что weak-ссылка всё ещё содержит объект: во время разрушения экземпляра среда выполнения может уже считать такую ссылку недействительной и вернуть nil. Надёжная гарантия Swift состоит в том, что после деаллокации объекта его weak-ссылки не указывают на освобождённую память.
ARC появился как автоматизация ручного управления подсчётом ссылок, где разработчик сам расставлял операции удержания и освобождения объекта. Для безопасного ненадлежащего владения были нужны специальные ссылки, которые не продлевают жизнь объекта и корректно переживают его уничтожение.
Weak-ссылки решают проблему висячих ссылок: после уничтожения объекта они становятся nil. Однако разрушение объекта — это не мгновенная операция: сначала выполняется deinit, затем освобождается память, поэтому полагаться на конкретный промежуточный момент обнуления ссылки небезопасно.
Представим объект, который в deinit обращается к другому объекту через weak-ссылку. Разработчик может ошибочно предположить, что раз deinit ещё выполняется, слабая ссылка обязательно доступна.
Такой код создаёт зависимость от деталей порядка разрушения. Результатом может стать nil вместо ожидаемого объекта, пропущенная очистка ресурса или логика, которая работает только при текущей версии компилятора и среды выполнения.
weak-ссылка не владеет объектом и не увеличивает его сильный счётчик ссылок. Когда последний владеющий объектом источник исчезает, экземпляр переходит к разрушению; во время этого процесса его состояние уже нельзя рассматривать как обычное полностью живое состояние.
deinit вызывается перед окончательным освобождением памяти экземпляра, но Swift не предоставляет контракт, на который можно было бы опереться для использования произвольных weak-ссылок именно в этот промежуточный момент. Поэтому проверка nil обязательна, а бизнес-логику нельзя строить на том, что слабая ссылка сохранит значение до конца deinit.
Если очистка требует гарантированно доступного объекта, её следует выполнять раньше — например, в явном методе остановки или при снятии владельцем связи с объектом. deinit лучше оставлять для финального освобождения ресурсов, которое не зависит от доступности других объектов через weak.
Это отличается от strong-ссылки: она удерживает объект живым, пока существует. Unowned-ссылка также не продлевает время жизни, но при обращении после уничтожения объекта приводит к аварийному завершению, поэтому она не является безопасной заменой weak во время разрушения.
Сервис хранит слабую ссылку на делегата и в deinit пытается уведомить его об остановке. Вариант с прямым обращением к weak-ссылке прост, но ненадёжен: делегат может быть недоступен, а порядок разрушения объектов не должен определять корректность завершения сервиса.
Можно сделать ссылку strong, но это способно создать цикл владения и задержать уничтожение делегата. Можно заменить её на unowned, однако при более долгом времени жизни сервиса это приведёт к аварийному завершению.
Практичное решение — явно завершать сервис до разрушения: владелец вызывает метод остановки, сервис прекращает работу и разрывает связи, а deinit использует только для защитной финальной очистки. Так результат не зависит от состояния weak-ссылок в момент деинициализации.
Означает ли вызов deinit, что объект уже недоступен?
Нет. deinit выполняется как часть процесса разрушения, до окончательного освобождения памяти. Но это не означает, что все внешние ссылки, особенно weak, обязаны оставаться пригодными для использования до завершения deinit.
Можно ли продлить жизнь другого объекта чтением weak-ссылки в deinit?
Нет. Чтение weak-ссылки не создаёт постоянного владения и не меняет время жизни объекта. Если объект ещё доступен, результат чтения можно временно использовать, но это не гарантирует его сохранность после завершения текущей операции.
Почему для очистки связи лучше не полагаться только на deinit?
Потому что deinit вызывается лишь тогда, когда сильных владельцев уже не осталось, и порядок уничтожения связанных объектов может быть сложным. Явное завершение работы позволяет контролировать порядок: сначала остановить операции, затем уведомить зависимые компоненты и разорвать связи, а deinit оставить как последний защитный барьер.