El uso de referencias débiles es algo de lo que nunca he visto una implementación, así que estoy tratando de averiguar cuál es el caso de uso para ellos y cómo funcionaría la implementación. ¿Cuándo ha necesitado usar un WeakHashMapo WeakReferencey cómo se usó?

Un problema con las referencias fuertes es el almacenamiento en caché, en particular con estructuras muy grandes como las imágenes. Supongamos que tiene una aplicación que tiene que trabajar con imágenes proporcionadas por el usuario, como la herramienta de diseño de sitios web en la que trabajo. Naturalmente, desea almacenar en caché estas imágenes, porque cargarlas desde el disco es muy costoso y desea evitar la posibilidad de tener dos copias de la imagen (potencialmente gigantesca) en la memoria a la vez.

Debido a que se supone que un caché de imágenes nos impide volver a cargar imágenes cuando no es absolutamente necesario, se dará cuenta rápidamente de que el caché siempre debe contener una referencia a cualquier imagen que ya esté en la memoria. Sin embargo, con referencias fuertes ordinarias, esa referencia en sí misma forzará a la imagen a permanecer en la memoria, lo que requiere que de alguna manera determine cuándo la imagen ya no es necesaria en la memoria y la elimine de la caché, para que sea elegible para la recolección de basura. Se ve obligado a duplicar el comportamiento del recolector de basura y determinar manualmente si un objeto debe estar en la memoria.

Comprender las referencias débiles , Ethan Nicholas

WeakReference versus SoftReference

Una distinción para ser clara es la diferencia entre a WeakReferencey a SoftReference.

Básicamente una WeakReferencehabrá GC-d por la JVM con impaciencia, una vez que el objeto referenciado no tiene duras referencias a ella. Un SoftReferenceobjeto d, por otro lado, tenderá a ser dejado por el recolector de basura hasta que realmente necesite recuperar la memoria.

Una memoria caché donde los valores se mantienen dentro de WeakReferences sería bastante inútil (en a WeakHashMap, son las claves las que están referenciadas débilmente). SoftReferencesson útiles para ajustar los valores cuando se desea implementar un caché que puede crecer y reducirse con la memoria disponible.

Un uso común de WeakReferencesys WeakHashMapen particular es para agregar propiedades a los objetos. Ocasionalmente, desea agregar alguna funcionalidad o datos a un objeto, pero la subclasificación y / o composición no son una opción, en ese caso, lo más obvio sería crear un hashmap que vincule el objeto que desea extender a la propiedad que desea agregar. . entonces, cuando necesite la propiedad, puede buscarla en el mapa. Sin embargo, si los objetos a los que está agregando propiedades tienden a destruirse y crearse mucho, puede terminar con una gran cantidad de objetos antiguos en su mapa que ocupan mucha memoria.

Si usa un WeakHashMaplugar, los objetos dejarán su mapa tan pronto como ya no los use el resto de su programa, que es el comportamiento deseado.

Tenía que hacer esto para añadir algunos datos para java.awt.Componentmoverse por un cambio en el JRE entre 1.4.2 y 1.5, podría haber arreglado subclasificando todos los componentes que estaba interesado int ( JButton, JFrame, JPanel....) pero esto fue mucho más fácil con mucho menos código.

Otro caso útil para WeakHashMapy WeakReferencees una implementación de registro de escucha .

Cuando crea algo que quiere escuchar ciertos eventos, generalmente registra un oyente, por ejemplo

manager.registerListener(myListenerImpl);

Si manageralmacena su oyente con a WeakReference, eso significa que no necesita eliminar el registro, por ejemplo, con un manager.removeListener(myListenerImpl)porque se eliminará automáticamente una vez que su oyente o su componente que lo tiene no esté disponible.

Por supuesto, aún puede eliminar manualmente su escucha, pero si no lo hace o lo olvida, no causará una pérdida de memoria y no evitará que su escucha se recolecte basura.

¿Dónde WeakHashMapentra en escena?

El registro de oyentes que desea almacenar oyentes registrados como WeakReferences necesita una colección para almacenar estas referencias. No hay WeakHashSetimplementación en la biblioteca estándar de Java solo a WeakHashMappero podemos usar fácilmente la última para "implementar" la funcionalidad de la primera:

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

Con esto listenerSetpara registrar un nuevo oyente, solo tiene que agregarlo al conjunto, e incluso si no se elimina explícitamente, si el oyente ya no está referenciado, la JVM lo eliminará automáticamente.

Esta publicación de blog muestra el uso de ambas clases: Java: sincronización en una ID . El uso es algo como esto:

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 proporciona objetos basados ​​en id para sincronizar. Los requisitos son:

• debe devolver una referencia al mismo objeto para el uso concurrente de ID equivalentes
• debe devolver un objeto diferente para diferentes ID
• sin mecanismo de liberación (los objetos no se devuelven al proveedor)
• no debe tener fugas (los objetos no utilizados son elegibles para la recolección de basura)

Esto se logra utilizando un mapa de almacenamiento interno de tipo:

WeakHashMap<Mutex, WeakReference<Mutex>>

El objeto es clave y valor. Cuando nada externo al mapa tiene una referencia dura al objeto, puede ser basura recolectada. Los valores en el mapa se almacenan con referencias duras, por lo que el valor debe estar envuelto en una WeakReference para evitar una pérdida de memoria. Este último punto está cubierto en el javadoc .

Si, por ejemplo, desea realizar un seguimiento de todos los objetos creados de una determinada clase. Para permitir que estos objetos sean recolectados de basura, mantenga una lista / mapa de referencias débiles a los objetos en lugar de los objetos en sí.

Ahora, si alguien pudiera explicarme referencias fantasmas, sería feliz ...

Como se indicó anteriormente, las referencias débiles se mantienen mientras exista una referencia fuerte.

Un ejemplo de uso sería usar WeakReference dentro de los oyentes, para que los oyentes ya no estén activos una vez que la referencia principal a su objeto de destino desaparezca. Tenga en cuenta que esto no significa que WeakReference se elimine de la lista de oyentes, la limpieza aún es necesaria, pero se puede realizar, por ejemplo, a horas programadas. Esto también tiene el efecto de evitar que el objeto escuchado contenga fuertes referencias y eventualmente sea una fuente de hinchazón de memoria. Ejemplo: componentes de la interfaz gráfica de usuario de Swing que hacen referencia a un modelo que tiene un ciclo de vida más largo que la ventana.

Mientras jugaba con los oyentes como se describió anteriormente, nos dimos cuenta rápidamente de que los objetos se recogen "inmediatamente" desde el punto de vista del usuario.

Un uso del mundo real que tuve para WeakReferences es si tienes un solo objeto muy grande que rara vez se usa. No desea mantenerlo en la memoria cuando no es necesario; pero, si otro hilo necesita el mismo objeto, tampoco querrás dos de ellos en la memoria. Puede mantener una referencia débil al objeto en alguna parte, y referencias duras en los métodos que lo utilizan; cuando ambos métodos terminen, el objeto será recogido.

Hice una búsqueda en el código de Google para "new WeakHashMap ()".

Obtuve un montón de coincidencias del proyecto GNU classpath y

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

puede usar weakhashmap para implementar un almacenamiento en caché sin recursos para la creación de objetos expansivos.

pero tenga en cuenta que no es deseable tener objetos mutables. Lo usé para almacenar en caché los resultados de la consulta (que tardan unos 400 ms en ejecutarse) en un motor de búsqueda de texto, que rara vez se actualiza.