Personalmente no me he encontrado con una situación en la que haya necesitado usar el tipo WeakReference en .Net, pero la creencia popular parece ser que debería usarse en cachés. El Dr. Jon Harrop dio un muy buen caso contra el uso de WeakReferences en cachés en su respuesta a esta pregunta.

También he escuchado a menudo que los desarrolladores de AS3 hablan sobre el uso de referencias débiles para ahorrar en la huella de la memoria, pero según las conversaciones que he tenido, parece agregar complejidad sin lograr necesariamente el objetivo previsto, y el comportamiento en tiempo de ejecución es bastante impredecible. Tanto es así que muchos simplemente se dan por vencidos y, en cambio, administran el uso de la memoria con más cuidado / optimizan su código para que consuman menos memoria (o para compensar más ciclos de CPU y menor huella de memoria).

El Dr. Jon Harrop también señaló en su respuesta que las referencias débiles .Net no son suaves, y hay una colección agresiva de referencias débiles en gen0. Según MSDN , ¡las referencias largas y débiles le brindan el potencial de recrear un objeto but the state of the object remains unpredictable.!

Dadas estas características, no puedo pensar en una situación en la que las referencias débiles serían útiles, ¿tal vez alguien podría iluminarme?

He encontrado aplicaciones prácticas legítimas de referencias débiles en los siguientes tres escenarios del mundo real que realmente me sucedieron personalmente:

Aplicación 1: controladores de eventos

Eres emprendedor Su empresa vende un control de líneas de chispa para WPF. Las ventas son excelentes, pero los costos de soporte lo están matando. Demasiados clientes se quejan de la acumulación de CPU y las pérdidas de memoria cuando se desplazan a través de pantallas llenas de líneas de chispa. El problema es que su aplicación está creando nuevas líneas de chispa a medida que aparecen, pero el enlace de datos está evitando que las viejas se recojan. ¿Qué haces?

Introduzca una referencia débil entre el enlace de datos y su control para que el enlace de datos solo ya no evite que su control se recolecte basura. Luego, agregue un finalizador a su control que elimine el enlace de datos cuando se recopile.

Aplicación 2: gráficos mutables

Eres el próximo John Carmack. Has inventado una nueva representación ingeniosa basada en gráficos de superficies de subdivisión jerárquica que hace que los juegos de Tim Sweeney parezcan una Nintendo Wii. Obviamente, no voy a decir exactamente cómo funciona, pero todo se centra en este gráfico mutable donde los vecinos de un vértice se pueden encontrar en a Dictionary<Vertex, SortedSet<Vertex>>. La topología del gráfico sigue cambiando a medida que el jugador corre. Solo hay un problema: su estructura de datos está eliminando subgráficos inalcanzables a medida que se ejecuta y necesita eliminarlos o perderá memoria. Afortunadamente, eres un genio, así que sabes que hay una clase de algoritmos diseñados específicamente para localizar y recolectar subgrafías inalcanzables: ¡recolectores de basura! Uno lee excelente monografía Richard Jones' sobre el temapero te deja perplejo y preocupado por tu inminente plazo. ¿Qué haces?

¡Simplemente reemplazando su Dictionarycon una tabla de hash débil, puede aprovechar el GC existente y hacer que recopile automáticamente sus subgrafos inalcanzables para usted! Volver a hojear los anuncios de Ferrari.

Aplicación 3: Decorar árboles

Estás colgado del techo de una habitación cilíndrica con un teclado. Tienes 60 segundos para examinar BIG DATA antes de que alguien te encuentre. Llegaste preparado con un hermoso analizador basado en secuencias que se basa en el GC para recolectar fragmentos de AST después de haber sido analizados. Pero se da cuenta de que necesita metadatos adicionales en cada AST Nodey que los necesita rápidamente. ¿Qué haces?

Puede usar a Dictionary<Node, Metadata>para asociar metadatos con cada nodo, pero, a menos que lo borre, las fuertes referencias del diccionario a los nodos AST antiguos los mantendrán vivos y perderán memoria. La solución es una tabla hash débil que mantiene solo referencias débiles a las claves y la basura recolecta enlaces de valores clave cuando la clave se vuelve inalcanzable. Luego, a medida que los nodos AST se vuelven inalcanzables, se recogen basura y su enlace clave-valor se elimina del diccionario, dejando los metadatos correspondientes inalcanzables para que también se recopilen. Luego, todo lo que tiene que hacer después de que su circuito principal haya terminado es deslizarse hacia arriba a través del respiradero recordando reemplazarlo justo cuando entra el guardia de seguridad.

Tenga en cuenta que en las tres aplicaciones del mundo real que realmente me sucedieron, quería que el GC se recopilara de la forma más agresiva posible. Es por eso que estas son aplicaciones legítimas. Todos los demás están equivocados.

Dadas estas características, no puedo pensar en una situación en la que las referencias débiles serían útiles, ¿tal vez alguien podría iluminarme?

Documento de Microsoft Patrones de eventos débiles .

En las aplicaciones, es posible que los controladores que están conectados a las fuentes de eventos no se destruyan en coordinación con el objeto de escucha que adjuntó el controlador a la fuente. Esta situación puede provocar pérdidas de memoria. Windows Presentation Foundation (WPF) presenta un patrón de diseño que puede usarse para abordar este problema, proporcionando una clase de administrador dedicada para eventos particulares e implementando una interfaz en los oyentes para ese evento. Este patrón de diseño se conoce como el patrón de evento débil.

...

El patrón de evento débil está diseñado para resolver este problema de pérdida de memoria. El patrón de evento débil se puede usar cuando un oyente necesita registrarse para un evento, pero el oyente no sabe explícitamente cuándo cancelar el registro. El patrón de evento débil también se puede usar siempre que la vida útil del objeto de la fuente exceda la vida útil útil del objeto del oyente. (En este caso, útil lo determina usted.) El patrón de evento débil permite que el oyente se registre y reciba el evento sin afectar de ninguna manera las características de vida útil del objeto del oyente. En efecto, la referencia implícita de la fuente no determina si el oyente es elegible para la recolección de basura. La referencia es una referencia débil, por lo tanto, el nombre del patrón de evento débil y las API relacionadas. El oyente puede recolectarse basura o destruirse de otra manera, y la fuente puede continuar sin retener referencias de manejador no coleccionables a un objeto ahora destruido.

Déjame poner esto primero y volver a ello:

Una referencia débil es útil cuando desea mantener pestañas en un objeto, pero NO desea que sus observaciones eviten que se recopile ese objeto

Entonces, comencemos desde el principio:

- Disculpas de antemano por cualquier ofensa no intencional, pero voy a retroceder al nivel de "Dick y Jane" por un momento ya que uno nunca puede decirle a la audiencia.

Entonces, cuando tienes un objeto X, especificémoslo como una instancia de class Foo, NO PUEDE vivir solo (principalmente cierto); De la misma manera que "Ningún hombre es una isla", solo hay unas pocas formas en que un objeto puede promoverse a Islandhood, aunque se llama ser una raíz GC en CLR. Ser una Raíz GC, o tener una cadena establecida de conexiones / referencias a una raíz GC, es básicamente lo que determina si Foo x = new Foo()se recolecta o no la basura.

Si no puede caminar de regreso a alguna raíz del GC, ya sea caminando por el montón o apilando, queda efectivamente huérfano y probablemente será marcado / recogido el próximo ciclo.

En este punto, veamos algunos ejemplos horriblemente inventados:

Primero, nuestro Foo:

public class Foo 
{
    private static volatile int _ref = 0;
    public event EventHandler FooEvent;
    public Foo()
    {
        _ref++;
        Console.WriteLine("I am #{0}", _ref);
    }
    ~Foo()
    {
        Console.WriteLine("#{0} dying!", _ref--);
    }
}

Bastante simple: no es seguro para subprocesos, así que no intente eso, pero mantiene un "recuento de referencias" aproximado de instancias activas y decrementos cuando se finalizan.

Ahora echemos un vistazo a FooConsumer:

public class NastySingleton
{
    // Static member status is one way to "get promoted" to a GC root...
    private static NastySingleton _instance = new NastySingleton();
    public static NastySingleton Instance { get { return _instance;} }

    // testing out "Hard references"
    private Dictionary<Foo, int> _counter = new Dictionary<Foo,int>();
    // testing out "Weak references"
    private Dictionary<WeakReference, int> _weakCounter = new Dictionary<WeakReference,int>();

    // Creates a strong link to Foo instance
    public void ListenToThisFoo(Foo foo)
    {
        _counter[foo] = 0;
        foo.FooEvent += (o, e) => _counter[foo]++;
    }

    // Creates a weak link to Foo instance
    public void ListenToThisFooWeakly(Foo foo)
    {
        WeakReference fooRef = new WeakReference(foo);
        _weakCounter[fooRef] = 0;
        foo.FooEvent += (o, e) => _weakCounter[fooRef]++;
    }

    private void HandleEvent(object sender, EventArgs args, Foo originalfoo)
    {
        Console.WriteLine("Derp");
    }
}

Entonces, tenemos un objeto que ya es una raíz de GC propia (bueno ... para ser específicos, se enraizará a través de una cadena directamente al dominio de la aplicación que ejecuta esta aplicación, pero ese es otro tema) que tiene dos métodos de engancharse a una Fooinstancia - probémoslo:

// Our foo
var f = new Foo();

// Create a "hard reference"
NastySingleton.Instance.ListenToThisFoo(f);

// Ok, we're done with this foo
f = null;

// Force collection of all orphaned objects
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

Ahora, a partir de lo anterior, ¿esperaría que el objeto al que se hizo referencia alguna vez ffuera "coleccionable"?

No, porque ahora hay otro objeto que tiene una referencia a él, el Dictionaryde esa Singletoninstancia estática.

Ok, intentemos con el enfoque débil:

f = new Foo();
NastySingleton.Instance.ListenToThisFooWeakly(f);

// Ok, we're done with this foo
f = null;

// Force collection of all orphaned objects
// This should collect # 2 - you'll see a "#2 dying"
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

Ahora, cuando criticamos nuestra referencia a lo Fooque fue una vez f, no hay más referencias "duras" al objeto, por lo que es coleccionable: lo WeakReferencecreado por el oyente débil no lo impedirá.

Buenos casos de uso:

• Controladores de eventos (aunque lea esto primero: Eventos débiles en C # )

• Tienes una situación en la que causarías una "referencia recursiva" (es decir, el objeto A se refiere al objeto B, que se refiere al objeto A, también conocido como "Fuga de memoria") (editar: derp, por supuesto, esto no es no es cierto)

• Desea "transmitir" algo a una colección de objetos, pero no quiere ser lo que los mantenga vivos; a List<WeakReference>puede mantenerse fácilmente e incluso podarse quitando donderef.Target == null

Al igual que las filtraciones lógicas que son realmente difíciles de rastrear, mientras que los usuarios tienden a notar que ejecutar su software durante mucho tiempo tiende a ocupar más y más memoria y se vuelve más y más lento hasta que se reinicia. Yo no.

Tenga en cuenta lo que sucede si, cuando el usuario solicita eliminar el recurso de la aplicación anterior, Thing2no puede manejar adecuadamente dicho evento en:

1. Punteros
2. Referencias fuertes
3. Referencias débiles

... y bajo cuál de estos errores probablemente quedaría atrapado durante las pruebas, y cuál no y volaría bajo el radar como un insecto de caza furtivo. La propiedad compartida es, más a menudo que la mayoría, una idea sin sentido.

Un ejemplo muy ilustrativo de referencias débiles utilizadas con buenos resultados es la ConditionalWeakTable , que es utilizada por el DLR (entre otros lugares) para adjuntar "miembros" adicionales a los objetos.

No quieres que la mesa mantenga vivo el objeto. Este concepto simplemente no podría funcionar sin referencias débiles.

Pero me parece que todos los usos de las referencias débiles llegaron mucho después de que se agregaron al lenguaje, ya que las referencias débiles han sido parte de .NET desde la versión 1.1. Simplemente parece algo que le gustaría agregar, de modo que la falta de destrucción determinista no lo arrinconará en lo que respecta a las características del lenguaje.

Si tiene implementada la capa de caché con C #, es mucho mejor colocar sus datos en la caché como referencias débiles, podría ayudar a mejorar el rendimiento de la capa de caché.

Piense que ese enfoque también podría aplicarse a la implementación de la sesión. Debido a que la sesión es un objeto de larga vida la mayor parte del tiempo, podría ser algún caso cuando no tiene memoria para un nuevo usuario. En ese caso, será mucho mejor eliminar otro objeto de sesión de usuario y luego lanzar OutOfMemoryException.

Además, si tiene un objeto grande en su aplicación (alguna tabla de búsqueda grande, etc.), eso debería usarse muy raramente y recrear dicho objeto no es un procedimiento muy costoso. Entonces mejor que sea una referencia semanal para tener una manera de liberar tu memoria cuando realmente lo necesites.