Altri usi di riferimenti deboli?

Question

So che i riferimenti deboli sono un buon candidato per i gruppi di dati potenzialmente grandi memoizing e Wikipedia's article on weak references elenca solo "tenere traccia delle variabili correnti a cui si fa riferimento nell'applicazione" e l'istruzione "Un altro uso di riferimenti deboli è scrivere una cache ".

Quali sono alcune altre situazioni (più specifiche del semplice "risultato di memorizzazione nella cache") in cui l'uso di riferimenti deboli è Una buona idea ^TM?

Answer 1

In Flex, use weak references to avoid memory leaks.

Se un gestore eventi è un membro di un oggetto istanza di breve durata, passare il gestore come riferimento forte a un oggetto che vivrà più a lungo può mantenere in vita l'istanza di breve durata senza motivo.

Answer 2

posso utilizzare riferimenti deboli per un paio di cose ...

mi piace creare "Eventi deboli" in .Net per evitare osservabili da mantenere viva osservatori troppo a lungo.

Ho anche utilizzato eventi deboli a detect memory leaks.

Answer 3

In Python, il garbage collector utilizza il conteggio dei riferimenti per decidere quando "distruggere" o altrimenti rilasciare un oggetto. Un riferimento circolare normale può comportare che gli oggetti non vengano mai raccolti dalla garbage perché il loro conteggio di riferimento rimane rispettivamente pari a 1 o superiore; ma using weak references consentirà a entrambi/tutti gli oggetti di essere ripuliti correttamente quando escono dall'ambito.

Answer 4

L'uso corretto primario per riferimenti deboli è identificare le cose la cui importanza deriva dall'esistenza di riferimenti forti a loro. I due scenari più comuni sono sia:

• Un oggetto contiene un riferimento a qualcosa non perché "preoccupazioni" circa l'oggetto in questione, ma piuttosto perché gli altri soggetti che si preoccupano per l'oggetto potrebbe desiderare per fare qualcosa con esso. Se dopo un po 'nessuno si preoccupa più dell'oggetto, non c'è motivo per cui altre entità debbano continuare a manipolarlo per conto di "tutte le entità che ne hanno a cuore".

• Il costo di memoria di contenere molti riferimenti allo stesso oggetto immutabile può essere molto inferiore al costo di memoria di contenere riferimenti a molti oggetti identici e il confronto di riferimenti allo stesso oggetto può essere molto più veloce rispetto al confronto di oggetti identici. Il costo di memoria della creazione di un oggetto immutabile, l'abbandono, il suo incasso e la creazione di un oggetto identico è essenzialmente uguale al costo di creazione di un oggetto e in seguito restituisce un secondo riferimento ad esso. Restituire un riferimento a un oggetto esistente che dovrebbe essere comunque mantenuto è una grande vittoria; restituire un riferimento a un oggetto che era idoneo per la raccolta ma che non era stato ancora raccolto potrebbe essere o non essere una vittoria (di solito è una leggera vittoria, ma in un GC generazionale a volte può danneggiare leggermente le prestazioni); in molti casi, questi ultimi benefici non sarebbero sufficienti a giustificare il mantenimento di un oggetto vivo più a lungo di quanto sarebbe altrimenti necessario.