2011-05-24 15 views
6

Tengo curiosidad por la duración del objeto compartido/estático en un dominio de aplicación donde las llamadas Remoting son la causa de la creación de los objetos compartidos.Vida útil remota para objetos estáticos en el dominio de la aplicación con objetos activados por el cliente

Estamos usando una configuración de Remoting que usa objetos activados por el cliente de los cuales solo usamos las funciones para llegar al servidor. Los objetos remotos se configuran como singletons.

El servidor configura un canal y utiliza RemotingConfiguration.Configure para cargar un archivo de configuración.

Algunas de estas funciones del servidor tocan y usan algunas variables estáticas (compartidas en vb.net) en el servidor. No puedo averiguar cuál es la duración de estas variables estáticas, se crean (se ejecuta el constructor estático) cuando se tocan por primera vez. Usando el registro no puedo ver que los objetos se deshagan/finalicen.

Esperando un par de minutos después de conectarse al servidor remoto, los objetos compartidos estarán vivos y en buen estado.

La pregunta:

Entonces, ¿qué es el tiempo en directo esperado de objetos estáticos en esta configuración de interacción remota. ¿Viven tan lejos como AppDomain o se ciclan cuando se intercambian los objetos Remoting? ¿Y cuál es la forma correcta de extender su vida útil si es necesario?

La respuesta:

tipos estáticos viven en dominio de aplicación, ya que accede por primera vez hasta el dominio de aplicación se descarga. Por lo tanto, no necesita prolongar su vida útil mientras AppDomain se esté ejecutando.

Respuesta

3

Los campos estáticos nunca se recogen en la basura. Eche un vistazo al Jeffrey Richter's article.
El Recolector de basura considera los campos estáticos como una raíz, por lo que Garbage Collector siempre asumirá que se usan los campos estáticos.

Los campos estáticos se inicializan cuando se carga el tipo de propietario. El compilador JIT carga el tipo cuando necesita construir un método y ve referencia a este tipo. Una vez cargado, el tipo permanece allí para toda la vida útil de AppDomain, por lo tanto, cualquier referencia a los campos que pertenecen al tipo (campos estáticos) se considerará como referencias usadas y no se recolectará como basura.

Además, con respecto a esta declaración:

no puedo averiguar cuál es el tiempo de vida de estas variables estáticas es, que reciben (se ejecuta constructor estático) creado cuando son tocados por la primer tiempo .

Las variables técnicamente estáticas no necesariamente se "tocan" la primera vez en el constructor estático. Considere clase como esta:

public static class Test 
{ 
    private static MyType myType; 

    static Test() 
    { 
     myType = new MyType(); 
    } 
} 

constructor estático (tipo constructor) no será llamado alguna vez, a menos que tenga el código que se está ejecutando y haciendo referencia a este tipo como var x = Test.myType;. Bueno, esto probablemente depende de lo que 'tocado' significa exactamente.

La respuesta:

tipos estáticos viven en dominio de aplicación, ya que accede por primera vez hasta el dominio de aplicación se descarga. Por lo tanto, no necesita prolongar su vida útil mientras AppDomain se esté ejecutando.

+0

El hecho de que los objetos estáticos sean considerados como raíz por el recolector de basura y nunca serán sometidos a GC es algo que nunca se debe olvidar. – CodingBarfield

5

Los objetos remotos no se recogen como basura hasta después de que expira el arrendamiento; el arrendamiento los protege del GC ya que no hay una referencia visible obvia para ellos. El período de arrendamiento predeterminado es de 5 minutos, el recolector de basura puede ejecutarse en otro par de minutos (dependiendo de la carga, el uso de memoria, etc.) y luego la última referencia a su objeto debería desaparecer. Solo después de que todo esto haya sucedido, se debe recopilar un objeto de instancia en el siguiente GC. Los objetos estáticos, sin embargo, no serán basura recolectada en absoluto.

En cuanto a la segunda parte de la pregunta, la forma correcta de extender la duración se llama "patrocinio": básicamente, cuando expira el contrato, el servidor pregunta a los clientes si alguien desea continuar utilizando este objeto. Hay un artículo bastante detallado sobre el tema here. No solo establezca la vida útil hasta el infinito.

+0

He leído el artículo, pero esto es más sobre el proceso de alojamiento que las clases de Remoting. Los objetos Marshall By Reference se recopilan a tiempo pero tengo curiosidad sobre los objetos compartidos/estáticos. Disparar colecciones GC no parece limpiar los objetos estáticos. – CodingBarfield

+1

Encontré algo más: las clases estáticas no parecen ser basura ** en absoluto **. Google: C# colección de basura de clase estática –

Cuestiones relacionadas