2009-07-08 13 views
25

Entiendo y aprecio la utilidad de la clase System.WeakReference en .NET framework, pero tengo curiosidad por los detalles de implementación.Implementación de WeakReference en .NET

¿Cómo se implementa WeakReference en .NET? MSDN analiza el uso de WeakReference en detalle, pero tiene pocos detalles que he visto sobre cómo funciona esto bajo el capó.

¿Cómo rastrea el CLR la referencia y sabe anular el identificador interno cuando se recopila el objetivo, sin impedir el GC? ¿Requiere un manejo especial en el CLR?

Mi principal preocupación sería si existen implicaciones de rendimiento al usar WeakReferences (especialmente si se usan muchas de ellas) que difieren de las de usar referencias de objeto estándar.

+5

Desde entonces he investigado un poco, y escribí en el blog mis hallazgos en detalle: http://reedcopsey.com/?p=50 –

Respuesta

19

La clase WeakReference pasa de la referencia de objeto al GC y recupera el control. Siempre que obtenga la referencia o verifique si la referencia está viva, el asa se utiliza para solicitar al GC la referencia.

Esto significa que el GC mantiene una lista de todas las referencias débiles, que debe actualizarse cuando se recopilan los objetos. También significa que hay una sobrecarga cada vez que usa una referencia débil.

Por lo tanto, cada referencia débil significa un poco más de trabajo para el recolector de basura, pero por otro lado también lo hace cada referencia regular, incluso si es menor. Por supuesto, debe ser un poco cuidadoso con el uso de muchas referencias débiles, pero si necesita eso para que la gestión de la memoria funcione bien con sus objetos, eso debería superar la pequeña sobrecarga que causa.

+1

Voy a establecer esto como la respuesta, ya que es una buena descripción básica del proceso. Gracias Guffa. –

13

Mencionaste MSDN; ¿Ya has visto este artículo?

http://msdn.microsoft.com/en-us/magazine/bb985011.aspx

También puedes ver el capítulo 19 en "Programación Aplicada Microsoft .NET Framework" por el mismo autor (Jeffrey Richter). El capítulo trata sobre la recolección de basura y tiene una sección sobre las partes internas de WeakReference.

En general, si tiene acceso a un montón de Targets dentro de WeakReferences, entonces hay un golpe de rendimiento simplemente porque el WeakRef hace algo de trabajo (sobre todo para la seguridad del hilo) antes de devolver el objetivo. Esto obviamente no es tan barato como usar la referencia de objeto directamente. Por otro lado, obtienes cierto rendimiento al almacenar referencias a objetos grandes, ya que el recolector de basura tiene más opciones cuando surgen consideraciones de memoria.

Nunca he tratado de cuantificar esta transacción, o conozco alguna referencia aquí. Obviamente, varía un poco dependiendo de la aplicación.

+2

+1, y gracias por el material de referencia. Solo FYI, investigué más y sorprendentemente hay poca sobrecarga para la seguridad de subprocesos en WeakReference: principalmente, se trata de tener que hacer que GCHandle devuelva el objeto, lo que actúa como desreferencia dos veces más un par de comprobaciones nulas. –

+0

Pensé que recordaba haberlo visto hace un par de años, pero realmente debería haberlo confirmado antes de ponerlo en la respuesta. Gracias por notar eso, Reed. – ars

+0

+1 para material de referencia útil. –

Cuestiones relacionadas