2009-05-12 16 views

Respuesta

19

Los objetos a los que se hace referencia por variables estáticas solo se recogerán cuando se recolecte el correspondiente AppDomain. En las aplicaciones cliente, a menudo solo hay un solo AppDomain que vive durante la duración del proceso. (Una excepción es cuando la aplicación utiliza una arquitectura plug-in -. Diferentes plug-ins se pueden cargar en diferentes AppDomain s y la AppDomain se pueden descargar más adelante)

En ASP.NET, "AppDomain reciclaje" sucede periódicamente (por varias razones): cuando esto ocurre, y las variables estáticas dentro de ese AppDomain ya no actuarán como raíces de GC, y por lo tanto no impedirán que los objetos sean recolectados como basura.

Sin embargo, si le preocupaba que un objeto fuera basura mientras todavía tenía una referencia a través de una variable estática, puede relajarse. Aunque puede acceder al objeto, no será basura recolectada.

+0

¿No crea esto una gran ineficacia? A menudo creo métodos privados de ayuda estática. O bien, todos los métodos de extensión. Me pregunto cuánta memoria consumen estos? Si tengo un método de ayuda para un objeto, ¿es mejor simplemente dejar el asistente como una instancia para que se recopile? –

+0

@ P.Brian.Mackey: si tienes métodos estáticos, ¿qué memoria crees que consumes? Si tiene * variables * estáticas, tiene estado global, que a menudo es una mala idea para empezar. Pero los métodos en sí mismos son una cuestión diferente. –

+0

Mi error. Supuse que los métodos se crean en las variables stack/heap like do. Aparentemente, ese no es el caso. –

5

Los miembros no se recopilan ... Los objetos son.
Entonces, si configura la Ref. Escriba static member en null, cualquier objeto al que apuntaba anteriormente se recolectaría. Si no, se mantendrá hasta que AppDomain baje (cada AppDomain tiene su propio conjunto de cosas estáticas)

0

Un miembro estático a un tipo de referencia es una referencia, que puede o no apuntar a una instancia. Si apunta a una instancia, dicha instancia no se recopilará hasta que se descargue el miembro estático. Si el tipo se carga en un AppDomain específico, se puede descargar. De lo contrario, solo ocurre cuando finaliza la aplicación.

1

La respuesta corta ... No; todas las implementaciones actuales del recolector de elementos no utilizados de .NET no recopilarán los objetos a los que hacen referencia los campos de miembros de clase estáticos, hasta que el dominio de aplicación con el que se asocian las referencias fuertes del campo de miembro de clase estático se anule.

La respuesta más larga ... Potencialmente sí; el recolector de basura basa su decisión en recolectar un objeto en la accesibilidad del objeto, no en las referencias (fuertes o débiles) al objeto. En teoría, si el recolector de basura pudiera determinar que ningún código requeriría un determinado objeto de nuevo desde un cierto punto en adelante (es decir, el objeto no es accesible desde ninguna ruta de código), el GC podría recoger ese objeto, incluso si aún estuviera fuertemente referenciado por campos de miembros de clase estáticos. Esto es perfectamente admisible, ya que nunca lo notaría, ya que ningún código intentaría acceder al campo miembro de la clase estática que contiene la referencia al objeto. Puede preguntar, entonces ¿por qué me importa si nunca volveré a acceder al objeto a través de alguna de las referencias sólidas que poseo? La razón por la que te importa son los efectos secundarios. Por ejemplo, puede suponer al asignar un campo de miembro de clase estática una referencia a un objeto SafeHandle, que representa un recurso no administrado, que el objeto SafeHandle nunca se cerraría y así mantendría vivo el "objeto" no gestionado que representa. Esto solo es cierto para las implementaciones actuales del GC. Una implementación futura del GC podría recopilar objetos fuertemente referenciados por campos de miembros de clase estáticos si esos objetos ya no fueran alcanzables por ninguno de los códigos de programa restantes.

Cuestiones relacionadas