Otros usos de referencias débiles?

Question

Sé que las referencias débiles son un buen candidato para memoizing potencialmente grandes conjuntos de datos, y Wikipedia's article on weak references solo enumera "realizar un seguimiento de las variables actuales a las que se hace referencia en la aplicación" y la declaración "Otro uso de referencias débiles es escribir un caché ".

¿Cuáles son algunas otras situaciones (más específicas que solo "resultados de almacenamiento en caché") donde el uso de referencias débiles es Una buena idea ^TM?

Answer 1

En Flex, use weak references to avoid memory leaks.

Si un controlador de eventos es miembro de un objeto de instancia efímera, pasar el controlador como una referencia fuerte a un objeto que durará más tiempo puede mantener viva la instancia de vida corta innecesariamente.

Answer 2

utilizo referencias débiles para algunas cosas ...

me gusta crear "Eventos débiles" en .Net para evitar observables de mantener viva observadores demasiado tiempo.

También he usado eventos débiles para detect memory leaks.

Answer 3

En Python, el recolector de basura utiliza el recuento de referencias para decidir cuándo "destruir" o desasignar un objeto. Una referencia circular normal puede hacer que los objetos nunca sean recolectados como basura porque sus recuentos de referencia permanecen en 1 o más; pero using weak references permitirá que ambos/todos los objetos se limpien adecuadamente cuando salgan del alcance.

Answer 4

El uso correcto principal para referencias débiles es identificar las cosas cuya importancia se deriva de la existencia de fuertes referencias a ellas. Los dos escenarios más comunes son cualquiera:

• Un objeto contiene una referencia a algo que no es porque "preocupaciones" sobre el objeto en cuestión, sino más bien por otras entidades que se preocupan por el objeto resultar útil que hacer algo con eso. Si después de un tiempo ya nadie se preocupa por el objeto, no hay razón por la cual otras entidades deberían continuar manipulándolo en nombre de "todas las entidades que se preocupan por él".

• El costo de memoria de mantener muchas referencias al mismo objeto inmutable puede ser mucho menor que el costo de memoria de mantener referencias a muchos objetos idénticos, y comparar referencias al mismo objeto puede ser mucho más rápido que comparar objetos idénticos. El costo de la memoria de crear un objeto inmutable, abandonarlo, hacer que se recopile y crear un objeto idéntico es esencialmente el mismo que el costo de crear un objeto y luego devolverle una segunda referencia. Devolver una referencia a un objeto existente que debería conservarse de todos modos es una gran ganancia; devolver una referencia a un objeto que era elegible para la recopilación pero que aún no se había recopilado puede ser o no una ganancia (generalmente es una ganancia leve, pero en un GC generacional a veces puede perjudicar el rendimiento levemente); en muchos casos, los últimos beneficios no serían suficientes para justificar el mantenimiento de un objeto con vida más tiempo del que sería necesario.