Приведи пример когда Unowned ссылка приведет к краху приложения

Отличный вопрос, который затрагивает одну из самых коварных и важных тем в управлении памятью Swift — ситуацию, когда unowned ссылка превращается в «висячую» (dangling reference) и приводит к немедленному краху приложения.

Суть проблемы с unowned

Ключевое отличие unowned от weak в том, что unowned ссылка — это неопциональная ссылка, не увеличивающая счетчик сильных ссылок (retain count), но при этом компилятор предполагает, что объект, на который она ссылается, будет жить дольше или, по крайней мере, столько же, сколько и сама unowned ссылка. Если этот объект освобождается из памяти, unowned ссылка не обнуляется (в отличие от weak), а указывает на недопустимую область памяти. Попытка обращения к ней вызывает неустранимый краш (EXC_BAD_ACCESS).

Классический и опасный пример: Двунаправленная связь с короткоживущим объектом

Рассмотрим типичный сценарий делегирования (delegation), где разработчик ошибочно использует unowned.

// MARK: - Протокол делегата
protocol DataLoaderDelegate: AnyObject {
    func dataDidLoad(data: String)
}

// MARK: - Класс, загружающий данные (служба)
class DataLoader {
    // ОШИБКА: Использование unowned здесь крайне рискованно.
    unowned var delegate: DataLoaderDelegate?

    func loadDataFromNetwork() {
        // Имитация асинхронной сетевой загрузки
        DispatchQueue.global().asyncAfter(deadline: .now() + 1.0) {
            let fakeData = "Данные с сервера"

            // Потенциальная точка краша! Что если `self.delegate` уже освобожден?
            DispatchQueue.main.async {
                self.delegate?.dataDidLoad(data: fakeData) // CRASH!
            }
        }
    }

    deinit {
        print("DataLoader деинициализирован.")
    }
}

// MARK: - Класс, использующий загрузчик (владелец)
class ViewController: DataLoaderDelegate {
    var loader: DataLoader?

    func setupLoader() {
        loader = DataLoader()
        loader?.delegate = self // Здесь устанавливается unowned ссылка.
    }

    func startLoading() {
        loader?.loadDataFromNetwork()
    }

    func dismissAndCleanup() {
        // Владелец решает освободить loader и завершить свою работу.
        loader = nil // DataLoader будет деинициализирован, т.к. на него больше нет сильных ссылок.
        print("ViewController освобождает loader.")
    }

    func dataDidLoad(data: String) {
        print("Получены данные: \(data)")
    }

    deinit {
        print("ViewController деинициализирован.")
    }
}

// MARK: - Симуляция жизненного цикла
func simulateCrashScenario() {
    var viewController: ViewController? = ViewController()
    viewController?.setupLoader()
    viewController?.startLoading()

    // Симулируем ситуацию, где ViewController "умирает" до завершения загрузки.
    // Например, пользователь закрыл экран.
    viewController?.dismissAndCleanup()
    viewController = nil // Деинициализируем ViewController.

    // В этот момент:
    // 1. Нет сильных ссылок на `ViewController` -> он деинициализируется.
    // 2. Нет сильных ссылок на `DataLoader` -> он тоже деинициализируется.
    // 3. Но... внутри асинхронного блока `loadDataFromNetwork` (который еще жив)
    //    существует UNOWNED-ссылка `self.delegate`, которая теперь указывает в никуда.

    // Через 1 секунду сработает блок `DispatchQueue.main.async` и попытается
    // вызвать `self.delegate?.dataDidLoad`. Обращение к освобожденной unowned
    // ссылке вызовет EXC_BAD_ACCESS и немедленный краш приложения.
}
// Если вызвать simulateCrashScenario(), краш практически гарантирован.

Почему именно здесь происходит краш? Пошаговый разбор:

1. Установка связи: ViewController создает и хранит сильную ссылку на DataLoader. DataLoader хранит unowned (неопциональную, но завуалированно опциональную через протокол) ссылку на делегата (ViewController). Счетчик сильных ссылок на ViewController равен 1.

2. Запуск асинхронной задачи: Вызывается loadDataFromNetwork(), который планирует выполнение блока через 1 секунду. Этот блок захватывает self (DataLoader) сильной ссылкой, чтобы быть уверенным, что DataLoader доживет до момента выполнения блока.

3. Преждевременное освобождение: До завершения загрузки (за 1 секунду) вызывается dismissAndCleanup(). ViewController обнуляет свойство loader. Теперь на DataLoader нет сильных ссылок (так как асинхронный блок еще не выполнился и не удерживал его напрямую в этом примере — но на практике он мог бы). DataLoader деинициализируется.

    *Важный нюанс:* Сам `ViewController` также может быть деинициализирован (если на него больше нет ссылок извне). Однако, даже если `ViewController` жив, но `DataLoader` умер — проблема уже наступила.

1. Фатальная попытка обращения: Через 1 секунду асинхронный блок выполняется. Строка self.delegate?.dataDidLoad(...) пытается разыменовать self.delegate. Поскольку delegate был объявлен как unowned, после деинициализации ViewController (или даже DataLoader, в зависимости от контекста захвата), эта ссылка становится «висячей». В отличие от weak, Swift не может безопасно проверить ее существование — она не равна nil. Попытка доступа приводит к обращению к очищенной памяти, что вызывает EXC_BAD_ACCESS (SIGSEGV) и падение приложения.

Как это исправить?

Правило простое: используйте unowned только тогда, когда вы абсолютно уверены, что время жизни referenced объекта больше или равно времени жизни referencing объекта. Классический безопасный пример — захват self в замыкании, которое гарантированно выполняется синхронно и до деинициализации self (например, в анимации UIView.animate(withDuration:...)).

В сценарии с асинхронными обратными вызовами и делегированием почти всегда нужно использовать weak.

// БЕЗОПАСНАЯ РЕАЛИЗАЦИЯ
class SafeDataLoader {
    weak var delegate: DataLoaderDelegate? // <-- CORRECT: weak reference

    func loadDataFromNetwork() {
        DispatchQueue.global().asyncAfter(deadline: .now() + 1.0) {
            let fakeData = "Данные с сервера"
            DispatchQueue.main.async { [weak self] in // Также слабый захват для безопасности
                // Теперь это безопасно. Если delegate или self уничтожены,
                // вызов просто не произойдет.
                self?.delegate?.dataDidLoad(data: fakeData)
            }
        }
    }
}

Вывод: Краш из-за unowned — это не случайность, а закономерный результат некорректной архитектурной предпосылки о времени жизни объектов. В условиях асинхронности, особенно в iOS, где пользователи активно закрывают и открывают экраны, weak является гораздо более предсказуемым и безопасным выбором для большинства обратных ссылок (delegate, closure captures).