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

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

Objective-C полагался на ручные циклы удержания/освобождения и прямые указатели для слабых ссылок, что требовало выполнения динамического свичинга или использования глобальных хеш-таблиц, что имело значительные накладные расходы на производительность при каждом доступе к объекту. Когда Apple разработало Swift, им понадобилась модель автоматического управления памятью, которая поддерживала нулевые слабые ссылки — автоматически становящиеся nil, когда ссылаемый объект деаллокировался — без нагрузки на подавляющее большинство объектов, которые никогда не сталкиваются со слабыми ссылками. Эта необходимость привела к разработке архитектуры побочных таблиц, которая экстернализирует метаданные слабых ссылок только при необходимости.

Центральная проблема заключалась в балансировке эффективности использования памяти и безопасности. Если бы заголовок каждого объекта содержал встроенное хранилище для отслеживания слабых ссылок (таких как связный список слабых указателей или встроенное количество слабых ссылок), то объем памяти для каждого экземпляра класса существенно увеличился бы, что негативно сказалось бы на производительном коде, использующем только сильные ссылки. С другой стороны, хранение слабых ссылок в глобальной хеш-таблице с ключом по адресу объекта вызывает узкие места синхронизации и сложную логику рекламации при деалокации объектов. Задача заключалась в создании механизма, который не накладывал бы никаких затрат на объекты без слабых ссылок, при этом гарантируя атомарное нулевое обнуление при исчезновении последней сильной ссылки.

Swift использует систему побочных таблиц, где заголовок каждого экземпляра класса содержитNullable указатель на отдельную структуру побочной таблицы, выделенную в куче. Эта побочная таблица хранит счетчик слабых ссылок и обратный указатель на объект; слабые ссылки фактически указывают на эту побочную таблицу, а не на объект напрямую. Когда счетчик сильных ссылок достигает нуля, время выполнения атомарно обнулит указатель объекта в побочной таблице, заставляя все существующие слабые ссылки видеть nil при следующем доступе, в то время как память объекта остается выделенной до тех пор, пока счетчик слабых ссылок также не достигнет нуля, после чего как побочная таблица, так и память объекта освобождаются.

Ситуация из жизни

Представьте, что вы разрабатываете высококачественный изображенческий конвейер для приложения социальной сети, где экземпляры ViewController загружают и отображают аватары пользователей. Чтобы предотвратить избыточные сетевые запросы, вы реализуете синглтон ImageCache, который хранит ссылки на загруженные объекты UIImage, чтобы несколько контроллеров представления, отображающих один и тот же аватар, могли делиться базовым буфером памяти.

Одним из рассматриваемых подходов было хранение сильных ссылок в NSCache с произвольной политикой эвакуации. Это гарантировало немедленный доступ и безопасность типов, но приводило к серьезным утечкам памяти, потому что кэш навсегда удерживал каждое изображение, в конечном итоге вызывая предупреждения о памяти и завершение работы приложения во время длительных сеансов прокрутки. Плюсы включали простоту и быстрый доступ, но минусы неограниченного роста памяти сделали его неподходящим для использования в производстве.

Другой рассмотренный подход заключался в реализации ручного паттерна наблюдателя, при котором контроллеры представления уведомляли кэш о деалокации, чтобы удалить конкретные записи с помощью протокола делегирования. Хотя это предотвращало утечки в теории, оно вводило хрупкую жесткую связанность между слоем представления и слоем кэширования, требовало значительного объема кода для обработки условий гонки во время быстрого перехода и рисковало авариями, если уведомления были пропущены или доставлены с опозданием.

Выбранное решение использовало родные слабые ссылки Swift в реализации кэша:

class ImageCache {
    private var cache: [URL: WeakBox<UIImage>] = [:]
    
    func image(for url: URL) -> UIImage? {
        return cache[url]?.value
    }
    
    func setImage(_ image: UIImage, for url: URL) {
        cache[url] = WeakBox(value: image)
    }
}

final class WeakBox<T: AnyObject> {
    weak var value: T?
    init(value: T) { self.value = value }
}

Декларируя значения словаря кэша как слабые через обертку WeakBox, ImageCache мог проверять, существует ли изображение в памяти, прежде чем вернуть его, позволяя автоматическую рекламацию, когда ни один контроллер представления активно не отображает этот аватар. Это устраняло как утечки памяти, так и накладные расходы на ручное ведение учета, что привело к снижению пикового использования памяти на 40% во время быстрой прокрутки лент и предотвратило завершение работы системой контроля памяти.

Что часто упускают кандидаты

Почему доступ к слабой ссылке может быть медленнее, чем доступ к сильной ссылке, и при каких конкретных условиях эта разница в производительности становится измеримой?

Доступ к слабой ссылке требует разыменования указателя побочной таблицы, хранящегося в заголовке объекта, а затем выполнения атомарной загрузки указателя объекта из этой побочной таблицы, чтобы проверить, был ли он обнулен. Хотя накладные расходы минимальны (обычно одно дополнительное разыменование), они становятся измеримыми при итерации по большим коллекциям (тысячи элементов), где каждый элемент доступен через слабую ссылку в жестких циклах, тогда как сильные ссылки требуют только одной погони за указателем без атомарных гарантий.

Что отличает не владельческую ссылку от слабой ссылки на уровне реализации, и почему попытка получить доступ к не владельческой ссылке после деалокации объекта вызывает сбой во время выполнения, а не возвращает nil?

В отличие от слабых ссылок, которые используют побочные таблицы для включения обнуления, не владельческие ссылки (в режиме по умолчанию с безопасностью) также ссылаются на побочную таблицу, но предполагают, что объект останется выделенным, пока существует не владельческая ссылка, вызывая сбой при деалокации объекта, потому что запись в побочной таблице помечена как уничтоженная, но не обнулена. Кандидаты часто упускают из виду, что небезопасные не владельческие ссылки полностью обходят побочную таблицу, ведя себя как висячие указатели C, которые повреждают память, когда к ним обращаются после деалокации, в то время как безопасные не владельческие ссылки по крайней мере определенно ловят сбой через бит деалокации в побочной таблице.

Почему память экземпляра объекта остается выделенной в куче, даже после завершения его deinit и удаления всех сильных ссылок, и когда эта память фактически освобождается?

Память сохраняется, потому что побочная таблица поддерживает счетчик слабых ссылок; заголовок объекта и связанное с ним хранилище не могут быть освобождены до тех пор, пока счетчик слабых ссылок не достигнет нуля, обеспечивая, чтобы слабые ссылки никогда не указывали на переработанную память. Только после уничтожения последней слабой ссылки (уменьшая счетчик слабых ссылок до нуля) время выполнения освобождает как побочную таблицу, так и область памяти объекта, процесс, невидимый для разработчиков, но критически важный для предотвращения уязвимостей использованной после освобождения.