Finalizador Estático

Question

¿Cuál es la forma correcta de realizar una finalización estática?

No hay destructor estático. El evento AppDomain.DomainUnload no se genera en el dominio predeterminado. El evento AppDomain.ProcessExit comparte el tiempo total de los tres segundos (configuración predeterminada) entre todos los controladores de eventos, por lo que no es realmente utilizable.

Answer 1

Básicamente, no puedes. Diseñe su camino en la mayor medida posible.

No olvides que un programa puede siempre terminar abruptamente de todos modos, alguien sacando el poder es el ejemplo obvio. Así que cualquier cosa que hagas tiene que ser "mejor esfuerzo" - en cuyo caso, ciertamente espero que AppDomain.ProcessExit sea lo suficientemente bueno.

¿Qué debe hacer en su caso particular?

Answer 2

  

Herfried Wagner ha escrito un excelente artículo explicando cómo implementar esto & # 8211 ; Por desgracia, en alemán (y VB). Aún así, el código debe ser comprensible.

Lo he probado:

static readonly Finalizer finalizer = new Finalizer();

sealed class Finalizer {
  ~Finalizer() {
    Thread.Sleep(1000);
    Console.WriteLine("one");
    Thread.Sleep(1000);
    Console.WriteLine("two");
    Thread.Sleep(1000);
    Console.WriteLine("three");
    Thread.Sleep(1000);
    Console.WriteLine("four");
    Thread.Sleep(1000);
    Console.WriteLine("five");
  }
}

Parece que funciona exactamente de la misma manera que lo hace el evento AppDomain.ProcessExit : el finalizador obtiene ca. tres segundos ...

Answer 3

Me preguntaría qué está cargando en sus métodos estáticos que necesitan ser liberados. Ciertamente no recomendaría hacer estas cosas en un método estático.

Dicho esto, su método estático podría crear una instancia de un objeto que tenga un método de finalización.

Answer 4

Dos soluciones que se te ocurren:

• No uses una clase estática. Si utiliza una clase no estática y la crea una instancia, no tiene que preocuparse tanto por la limpieza.
• Si esa no es una opción, argumentaría que esta es una buena situación para usar un singleton. Esto creará una instancia de una copia de su objeto y hará que se llame al finalizador al salir, pero aún así le permitirá tratarlo como una clase estática en su mayor parte. Después de todo, su clase ya es estática y, por lo tanto, comparte la mayoría de las razones comunes para no usar un singleton.

Answer 5

Para portar la respuesta de Michael Damatov (C #) que se basa en Herfried K. Wagner. (VB.NET) aquí está la versión de C ++ / CLI:

ref class MyClass
{
        ref class StaticFinalizer sealed
        {
            !StaticFinalizer();
        };
        static initonly StaticFinalizer^ stDestr = gcnew StaticFinalizer();
}

MyClass::StaticFinalizer::!StaticFinalizer()
{
    System::Diagnostics::Debug::WriteLine("In StaticFinalizer!");
}

P.S. Al igual que el método AppDomain.ProcessExit, es posible que no se llame a este si el proceso finaliza de manera anormal (por ejemplo, desde el Administrador de tareas). Otra advertencia es que si MyClass es genérico (con plantilla), la suposición de que su constructor estático y su destructor estático se llamarán no más de una vez por ejecución de la aplicación ya no será válida.