Risposta alla domanda.
Objective-C si basava su cicli di retain/release manuali e puntatori diretti per riferimenti weak, che richiedevano swizzling a runtime o tabelle hash globali che comportavano penalizzazioni delle prestazioni significative ad ogni accesso a oggetti. Quando Apple ha progettato Swift, hanno richiesto un modello di gestione automatica della memoria che supportasse riferimenti weak a zero—diventando automaticamente nil quando l'oggetto referenziato veniva deallocato—senza gravare sulla stragrande maggioranza degli oggetti che non incontrano riferimenti weak. Questa necessità ha portato allo sviluppo di un'architettura di side-table che esternalizza i metadati dei riferimenti weak solo quando necessario.
Il problema centrale consisteva nel bilanciare l'efficienza della memoria e la sicurezza. Se ogni intestazione di oggetto conteneva uno spazio di archiviazione inline per il tracciamento dei riferimenti weak (come una lista collegata di puntatori weak o un conteggio weak inline), l'impronta di memoria di ogni istanza di classe sarebbe aumentata sostanzialmente, penalizzando il codice critico per le prestazioni che utilizza solo riferimenti forti. D'altra parte, memorizzare riferimenti weak in una tabella hash globale indicizzata dall'indirizzo dell'oggetto introduce colli di bottiglia di sincronizzazione e logica di reclamazione complessa quando gli oggetti vengono deallocati. La sfida stava nel creare un meccanismo che imponesse zero costi sugli oggetti senza riferimenti weak garantendo al contempo azioni atomiche thread-safe a zero quando l'ultimo riferimento forte spariva.
Swift impiega un sistema di side-table in cui ogni intestazione di istanza di classe contiene un puntatore nullable a una struttura di side table allocata nel heap separato. Questa side table memorizza il conteggio dei riferimenti weak e un puntatore inverso all'oggetto; i riferimenti weak puntano effettivamente a questa side table piuttosto che all'oggetto direttamente. Quando il conteggio dei riferimenti forti raggiunge zero, il runtime imposta in modo atomico a nil il puntatore dell'oggetto all'interno della side table, causando a tutti i riferimenti weak esistenti di osservare nil al prossimo accesso, mentre la memoria dell'oggetto rimane allocata fino a quando anche il conteggio dei riferimenti weak non raggiunge zero, momento in cui sia la side table che la memoria dell'oggetto vengono reclamate.
Situazione dalla vita reale
Immagina di sviluppare un pipeline di immagini ad alta risoluzione per un'applicazione di social media in cui le istanze di ViewController scaricano e visualizzano avatar degli utenti. Per prevenire richieste di rete ridondanti, implementi un singleton ImageCache che memorizza riferimenti agli oggetti UIImage scaricati in modo che più controller di vista che visualizzano lo stesso avatar possano condividere il buffer di memoria sottostante.
Un approccio considerato è stato quello di memorizzare riferimenti forti in un NSCache con politiche di espulsione arbitrarie. Questo garantiva accesso immediato e sicurezza di tipo ma causava gravi perdite di memoria poiché la cache conservava ogni immagine indefinitamente, attivando infine avvisi di memoria e terminazione dell'app durante sessioni di scorrimento prolungato. I pro includevano semplicità e accesso veloce, ma i contro della crescita della memoria illimitata lo rendevano improprio per la produzione.
Un altro approccio considerato ha implicato l'implementazione di un modello di osservazione manuale in cui i controller di vista notificavano la cache alla deallocazione per rimuovere voci specifiche utilizzando un protocollo delegate. Sebbene questo prevenga perdite in teoria, introduceva un accoppiamento stretto fragile tra il livello di visualizzazione e il livello di caching, richiedendo una notevole quantità di boilerplate per gestire condizioni di gara durante rapide transizioni di navigazione e rischiava di causare arresti anomali se i messaggi di notifica venivano persi o consegnati in ritardo.
La soluzione selezionata ha utilizzato i riferimenti weak nativi di Swift all'interno dell'implementazione della cache:
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 } }
Dichiarando i valori del dizionario della cache come weak tramite il wrapper WeakBox, il ImageCache poteva verificare se un'immagine esistesse ancora in memoria prima di restituirla, mentre consentiva la reclamazione automatica quando nessun controller di vista visualizzava attivamente quell'avatar. Questo ha eliminato sia le perdite di memoria che il sovraccarico della contabilità manuale, risultando in una riduzione del 40% nell'uso massimo della memoria durante lo scorrimento rapido dei feed e prevenendo la terminazione da parte del watchdog della memoria del sistema.
Cosa spesso dimenticano i candidati
Perché l'accesso a un riferimento weak può essere più lento rispetto all'accesso a un riferimento forte, e in quali specifiche condizioni questa differenza di prestazioni diventa misurabile?
L'accesso a un riferimento weak richiede di dereferenziare il puntatore della side table memorizzato nell'intestazione dell'oggetto, quindi eseguire un caricamento atomico del puntatore dell'oggetto da quella side table per controllare se è stato azzerato. Sebbene il sovraccarico sia minimo (tipicamente una singola indirettrice aggiuntiva), diventa misurabile quando si itera su collezioni ampie (migliaia di elementi) in cui ogni elemento è accesso attraverso un riferimento weak in cicli stretti, mentre i riferimenti forti richiedono solo una singola ricerca di puntatore senza garanzie atomiche.
Cosa distingue un riferimento unowned da un riferimento weak a livello di implementazione, e perché tentare di accedere a un riferimento unowned dopo la deallocazione dell'oggetto provoca un crash a runtime anziché restituire nil?
A differenza dei riferimenti weak che utilizzano le side table per abilitare l'azzeramento, i riferimenti unowned (nella modalità sicura predefinita) si riferiscono anch'essi alla side table ma presumono che l'oggetto rimanga allocato finché il riferimento unowned esiste, causando un arresto anomalo se l'oggetto viene deallocato perché l'entrata della side table è segnata come distrutta ma non azzerata. I candidati spesso dimenticano che i riferimenti unowned non sicuri bypassano completamente la side table, comportandosi come puntatori C pendenti che corrompono la memoria quando vengono accessi dopo la deallocazione, mentre i riferimenti unowned sicuri almeno intrappolano in modo deterministico tramite il bit deallocato della side table.
Perché la memoria di un'istanza di oggetto rimane allocata nel heap anche dopo il completamento del suo deinit e quando questa memoria viene effettivamente liberata?
La memoria persiste perché la side table mantiene un conteggio dei riferimenti weak; l'intestazione dell'oggetto e il suo spazio di archiviazione associato non possono essere reclamati fino a quando il conteggio weak non raggiunge zero, garantendo che i riferimenti weak non puntino mai a memoria riciclata. Solo dopo che l'ultimo riferimento weak è distrutto (decrementando il conteggio weak a zero) il runtime dealloca sia la side table che la regione di memoria dell'oggetto, un processo invisibile agli sviluppatori ma cruciale per prevenire vulnerabilità di uso dopo la liberazione.