L'uso di riferimenti deboli è qualcosa di cui non ho mai visto un'implementazione, quindi sto cercando di capire quale sia il caso d'uso per loro e come funzionerebbe l'implementazione. Quando hai dovuto usare un WeakHashMapoe WeakReferencecome è stato usato?

Un problema con riferimenti forti è la memorizzazione nella cache, in particolare con strutture molto grandi come le immagini. Supponiamo di avere un'applicazione che deve lavorare con immagini fornite dall'utente, come lo strumento di progettazione del sito Web su cui lavoro. Naturalmente vuoi memorizzare queste immagini nella cache, perché caricarle dal disco è molto costosa e vuoi evitare la possibilità di avere due copie dell'immagine (potenzialmente gigantesca) in memoria contemporaneamente.

Poiché una cache di immagini dovrebbe impedirci di ricaricare le immagini quando non ne abbiamo assolutamente bisogno, ti renderai presto conto che la cache dovrebbe sempre contenere un riferimento a qualsiasi immagine che è già in memoria. Con normali riferimenti forti, tuttavia, quel riferimento stesso costringerà l'immagine a rimanere in memoria, il che richiede in qualche modo determinare quando l'immagine non è più necessaria in memoria e rimuoverla dalla cache, in modo che diventi idonea per la garbage collection. Sei costretto a duplicare il comportamento del Garbage Collector e a determinare manualmente se un oggetto deve essere o meno in memoria.

Comprensione dei riferimenti deboli , Ethan Nicholas

WeakReference contro SoftReference

Una distinzione da chiarire è la differenza tra a WeakReferencee a SoftReference.

Fondamentalmente a WeakReferencesarà GC-d dalla JVM avidamente, una volta che l'oggetto referenziato non ha riferimenti concreti ad esso. Un SoftReferenceoggetto d, d'altra parte, tenderà a essere lasciato in giro dal garbage collector fino a quando non avrà davvero bisogno di recuperare la memoria.

Una cache in cui i valori sono contenuti all'interno di WeakReferences sarebbe piuttosto inutile (in a WeakHashMap, sono le chiavi a cui si fa debolmente riferimento). SoftReferencessono utili per racchiudere i valori quando si desidera implementare una cache che può crescere e ridursi con la memoria disponibile.

Un uso comune di WeakReferences e WeakHashMapin particolare è per l'aggiunta di proprietà agli oggetti. Occasionalmente vuoi aggiungere alcune funzionalità o dati a un oggetto ma la sottoclasse e / o la composizione non sono un'opzione in quel caso la cosa ovvia da fare sarebbe creare una hashmap che collega l'oggetto che vuoi estendere alla proprietà che vuoi aggiungere . quindi ogni volta che hai bisogno della proprietà puoi semplicemente cercarla nella mappa. Tuttavia, se gli oggetti a cui stai aggiungendo proprietà tendono a essere distrutti e creati molto, puoi finire con un sacco di vecchi oggetti nella tua mappa che occupano molta memoria.

Se usi un WeakHashMapinvece gli oggetti lasceranno la tua mappa non appena non saranno più utilizzati dal resto del programma, che è il comportamento desiderato.

Ho dovuto fare questo per aggiungere alcuni dati per java.awt.Componentaggirare un cambiamento nel JRE tra la 1.4.2 e 1.5, avrei potuto riparato da tutti i componenti sottoclasse ero int interessato ( JButton, JFrame, JPanel....), ma questo è stato molto più facile con molto meno codice.

Un altro caso utile per WeakHashMaped WeakReferenceè un'implementazione del registro dell'ascoltatore .

Quando crei qualcosa che vuole ascoltare determinati eventi, di solito registri un ascoltatore, ad es

manager.registerListener(myListenerImpl);

Se managermemorizza il tuo listener con a WeakReference, ciò significa che non è necessario rimuovere il registro, ad esempio con a manager.removeListener(myListenerImpl)perché verrà automaticamente rimosso una volta che il tuo listener o il tuo componente che detiene il listener diventa non disponibile.

Ovviamente puoi ancora rimuovere manualmente il tuo ascoltatore, ma se non lo dimentichi o lo dimentichi, non causerà una perdita di memoria e non impedirà che il tuo ascoltatore venga raccolto.

Da dove WeakHashMapviene l'immagine?

Il registro degli ascoltatori che desidera archiviare gli ascoltatori registrati come WeakReferences ha bisogno di una raccolta per memorizzare questi riferimenti. Non esiste WeakHashSetun'implementazione nella libreria Java standard solo a, WeakHashMapma possiamo facilmente usare quest'ultima per "implementare" la funzionalità della prima:

Set<ListenerType> listenerSet =
    Collections.newSetFromMap(new WeakHashMap<ListenerType, Boolean>());

Con questo listenerSetper registrare un nuovo listener devi solo aggiungerlo al set, e anche se non viene rimosso esplicitamente, se il listener non viene più referenziato, verrà rimosso automaticamente dalla JVM.

Questo post sul blog dimostra l'uso di entrambe le classi: Java: sincronizzazione su un ID . L'utilizzo è simile al seguente:

private static IdMutexProvider MUTEX_PROVIDER = new IdMutexProvider();

public void performTask(String resourceId) {
    IdMutexProvider.Mutex mutext = MUTEX_PROVIDER.getMutex(resourceId);
    synchronized (mutext) {
        // look up the resource and do something with it
    }
}

IdMutextProvider fornisce oggetti basati su ID per la sincronizzazione. I requisiti sono:

• deve restituire un riferimento allo stesso oggetto per l'uso simultaneo di ID equivalenti
• deve restituire un oggetto diverso per ID diversi
• nessun meccanismo di rilascio (gli oggetti non vengono restituiti al provider)
• non deve perdere (gli oggetti inutilizzati sono idonei per la garbage collection)

Ciò si ottiene utilizzando una mappa di archiviazione interna di tipo:

WeakHashMap<Mutex, WeakReference<Mutex>>

L'oggetto è sia chiave che valore. Quando nulla di esterno alla mappa ha un forte riferimento all'oggetto, può essere spazzato via. I valori nella mappa sono memorizzati con riferimenti concreti , quindi il valore deve essere racchiuso in un riferimento debole per evitare una perdita di memoria. Quest'ultimo punto è trattato nel javadoc .

Ad esempio, se si desidera tenere traccia di tutti gli oggetti creati di una determinata classe. Per consentire comunque la raccolta differenziata di questi oggetti, è necessario mantenere un elenco / una mappa di riferimenti deboli agli oggetti anziché agli oggetti stessi.

Ora, se qualcuno potesse spiegarmi riferimenti fantasma, sarei felice ...

Come indicato sopra, i riferimenti deboli vengono mantenuti fino a quando esiste un riferimento forte.

Un esempio potrebbe essere l'uso di WeakReference all'interno dei listener, in modo che i listener non siano più attivi una volta sparito il riferimento principale al loro oggetto target. Si noti che ciò non significa che WeakReference venga rimosso dall'elenco dei listener, è comunque necessario ripulire ma può essere eseguito, ad esempio, in orari programmati. Questo ha anche l'effetto di impedire all'oggetto ascoltato di contenere riferimenti forti e alla fine essere una fonte di memoria gonfia. Esempio: componenti della GUI di Swing che fanno riferimento a un modello con un ciclo di vita più lungo rispetto alla finestra.

Giocando con gli ascoltatori come descritto sopra, ci siamo rapidamente resi conto che gli oggetti venivano raccolti "immediatamente" dal punto di vista dell'utente.

Un uso nel mondo reale che ho avuto per WeakReferences è se hai un singolo oggetto molto grande che viene usato raramente. Non vuoi tenerlo in memoria quando non è necessario; ma, se un altro thread ha bisogno dello stesso oggetto, non ne vuoi nemmeno due in memoria. È possibile mantenere un riferimento debole all'oggetto da qualche parte e riferimenti duri nei metodi che lo utilizzano; quando entrambi i metodi finiscono, l'oggetto verrà raccolto.

Ho fatto una ricerca del codice di Google per "nuovo WeakHashMap ()".

Ho ricevuto un sacco di partite dal progetto GNU classpath e

1. Progetto Apache xbean: WeakHashMapEditor.java
2. Progetto Apache Lucene: CachingWrapperFilter.java

è possibile utilizzare weakhashmap per implementare una memorizzazione nella cache senza risorse per la creazione di oggetti espansiva.

ma nota che non è desiderabile avere oggetti mutabili. l'ho usato per memorizzare nella cache i risultati delle query (che richiedono circa 400 ms per essere eseguiti) su un motore di ricerca testuale, che raramente viene aggiornato.