[C#] ¿Cómo funciona el Garbage Collector? ( I ) – El blog de Andrés Pérez en Geeks.ms

Una de las principales diferencias respecto a C/C++ y similitudes con Java es la presencia del Garbage Collector (GC) que permite delegar en un proceso la gestión de los objetos que creamos. A priori nos olvidamos de tener que invocar de forma explícita el destructor de los objetos y liberar su memoria. Veamos qué ocurre realmente.

El GC aparece en la primera versión de .NET Framework. Su funcionamiento permite que hagamos cosas como estas:

class CustomObject
{
    public byte[] ByteArray { get; set; }
  
    public CustomObject()
    {
        this.ByteArray = new byte[1024];
    }
}

Vemos que creamos un objeto array de una longitud determinada y al finalizar el programa podemos comprobar a través de herramientas que no tenemos fugas de memoria. Si analizamos el código CIL generado podemos ver que no aparece tampoco ninguna mención a destruir nada. El GC, a través del Framework se encarga todo. Todo totalmente transparente.

Para seguir hablando de GC es necesario introducir el concepto básico de memoria en Stack y en el Heap. Para tratar este tema aconsejo este artículo y su segunda parte que tratan sobre el diseño e implementación del stack. Como añadido, este no vendrá mal. El resumen sencillo y algo banal es que todo tipo que se instancia irá alojado en el Heap que es autogestionado. Es decir, hay alguien que se encarga de una vez instanciado un objeto que ya se ha usado, determinar qué hacer con él.

Finalizadores

La primera aproximación siguiendo un paradigma OO será que al igual que un objeto tiene constructor debe tener un destructor. Al igual que en C++, C# posee este método siguiendo la misma nomenclatura para cualquier tipo de objeto:

class CustomObject
        {
            public byte[] ByteArray { get; set; }
  
            public CustomObject()
            {
                System.Console.Write("Object created");
            }
  
            ~CustomObject()
            {
                System.Console.Write("Finalizer invoked");
                System.Console.Read();
            }
        }

Donde podremos definir qué ocurre una vez se “destruye” el objeto. Realmente no se destruye, puesto que en C# se llama “finalizador”. Se finaliza la vida del objeto pero este sigue estando vivo. Simplemente funciona así porque el GC tiene varias fases que veremos más adelante. Pero analicemos este hecho un poco más en profundidad. Si obtenemos el código IL generado observamos el siguiente método:

.method family hidebysig virtual instance void 
        Finalize() cil managed
{
  // Code size       31 (0x1f)
  .maxstack  1
  .try
  {
    IL_0000:  nop
    IL_0001:  ldstr      "Finalizer invoked"
    IL_0006:  call       void [mscorlib]System.Console::Write(string)
    IL_000b:  nop
    IL_000c:  call       int32 [mscorlib]System.Console::Read()
    IL_0011:  pop
    IL_0012:  nop
    IL_0013:  leave.s    IL_001d
  }  // end .try
  finally
  {
    IL_0015:  ldarg.0
    IL_0016:  call       instance void [mscorlib]System.Object::Finalize()
    IL_001b:  nop
    IL_001c:  endfinally
  }  // end handler
  IL_001d:  nop
  IL_001e:  ret
} // end of method CustomObject::Finalize

Para IL no existe el concepto de destructor. Existe y transforma lo que llamaríamos un destructor en un finalizador, en un método llamado Finalize() que alguien invocará. De hecho, si intentamos declarar lo siguiente:

protected override void Finalize()
{
    //...
}

Vemos como el propio compilador no te permite declarar ese método y te sugiere que declares un destructor.

¿Qué se debe escribir en un finalizador? Liberación de recursos (streams, conexiones, etc) y al ser crítico, un código que no deba fallar ni provocar excepciones. Y la siguiente pregunta es: ¿no estaba IDisposable para esto? En efecto, en la página de MSDN nos cuentan que IDisposable sirve para liberar los recursos que no se pueden gestionar porque GC, al no ser determinístico no sabemos cuándo podrá lanzarse. Y además como son recursos que no se pueden gestionar, GC los ignorará. Típicos ejemplos de esto son los streams. Y por eso se recomienda cada vez que abrimos un stream, insertarlo dentro de un using. Cuando finaliza el using se invoca de forma automática al método Dispose(). Algo se vio en un artículo anterior.

Un ejemplo sencillo de cómo funciona y cómo implementar correctamente Dispose lo tenemos en el siguiente fragmento de código:

class DisposableObject : IDisposable
        {
            public void Dispose()
            {
                this.Dispose(true);
                GC.SuppressFinalize(this);
            }
  
            protected virtual void Dispose(bool disposing)
            {
                if (disposing)
                {
                    // Dispose on each object of this instance.
                    // ...
                }
            }
  
            ~DisposableObject()
            {
                this.Dispose(false);
            }
        }

Al implementar la interfaz IDisposable tenemos que implementar el método Dispose(). El patrón ofrece una estructuración de las llamadas a Dispose() del objeto actual y los objetos que se integren, de modo que si invocamos Dispose() se invocará el Dispose() de cada uno de los objetos que hayamos ido añadiendo. Sin embargo si se invoca al finalizador a través del “destructor”, el GC seguirá su curso. Nótese la diferencia entre Dispose() y el finalizador:

– Dispose(): Primero invoca al método protegido para que se invoquen en cascada los Dispose de cada objeto y posteriormente, se indica al GC que no es necesario que invoque al finalizador en este instante puesto que ya hemos liberado los recursos. ¿Necesario? No. ¿Optimizado? Un poco, puesto que ahorramos llamadas al GC.

– ~(): Simplemente invoca al Dispose(false) que no debería invocar al Dispose de los objetos internos. Desde el punto de vista nuestro respecto al GC, no sabemos en qué estado están y ya es función del GC determinar si debe ir a por ellos o no.

Siguiendo con la pregunta de ¿qué diferencia hay entre un finalizador y IDisposable? La respuesta a nivel teórico es: ninguna. Ambos están pensados para liberar aquellos recursos que empleamos en los objetos. La única diferencia es que tenemos un mecanismo para controlar cuándo lo llamamos si empleamos IDisposable; porque el finalizador, al depender de GC no podemos esperar nada de él. No sabemos cuándo será llamado.

A modo de resumen tenemos lo siguiente:

En C# NO podemos destruir los objetos. Como mucho podemos indicar qué ocurre cuando tienen algún recurso asociado y liberarlo.
IDisposable no se invoca sólo. Hay que invocarlo. E invocarlo, no significa destruir el objeto.
~() Es el método finalizador del objeto. Sólo es invocado a través del GC y cuando éste lo estima oportuno.

Finalizadores

Deja un comentario Cancelar respuesta