Desde la primera línea de código de este curso, .NET ha gestionado automáticamente la memoria de cada objeto creado con new: nunca has tenido que reservarla ni liberarla a mano, como sí haría falta en lenguajes como C o C++. Esa comodidad tiene un mecanismo detrás, el recolector de basura (Garbage Collector, GC), y unos límites claros: hay recursos —ficheros, conexiones de red o de base de datos— que el GC no sabe liberar por sí solo, y que dependen del patrón IDisposable/using ya visto en el Módulo 5. Esta lección explica cómo funciona el GC por dentro, retoma IDisposable con su forma completa (el patrón Dispose/finalizador), y expone una fuente de fugas de memoria muy real en C#: los eventos con suscriptores que nunca se desuscriben.

1. Pila (stack) y montón (heap): dónde vive cada dato
2. El recolector de basura: generaciones 0, 1 y 2
3. IDisposable y using/using var: repaso desde la lección de E/S de Archivos
4. El patrón Dispose/finalizador completo
5. GC.Collect(): por qué casi nunca se debe llamar manualmente
6. Fugas de memoria comunes en C#: eventos no desuscritos
7. Ejemplo: IDisposable completo sobre una conexión SQLite de BiblioTech

.NET reserva memoria en dos zonas con reglas de vida muy distintas:

Es importante distinguir la variable de lo que referencia: Libro libro1 = new Libro(...); guarda en la pila una referencia (una dirección de memoria) que apunta al objeto Libro real, creado en el montón por new. Cuando el método termina, esa referencia de la pila desaparece de inmediato; el objeto Libro del montón, en cambio, sigue existiendo hasta que el recolector de basura decide que ya no lo necesita nadie —tema del siguiente apartado. Los tipos valor (struct, como los vistos en la lección de Structs y Records del Módulo 3) sí pueden vivir enteramente en la pila cuando son variables locales, sin pasar por el montón en absoluto.

El recolector de basura de .NET libera automáticamente los objetos del montón que ya no tienen ninguna referencia accesible desde el programa —es decir, a los que ya no se puede llegar desde ninguna variable en uso—. Para no tener que examinar todo el montón cada vez, organiza los objetos en tres generaciones, basándose en una observación empírica: la mayoría de objetos mueren jóvenes (variables temporales de un método), y los que sobreviven tienden a vivir mucho tiempo (el catálogo completo de Biblioteca, por ejemplo):

Cuando el GC recolecta la generación 0 y encuentra que un objeto sigue teniendo referencias activas, lo promociona a la generación 1; si sobrevive también a una recolección de la generación 1, pasa a la generación 2. Esta estrategia —revisar con frecuencia lo que probablemente ya murió, y con poca frecuencia lo que probablemente seguirá vivo mucho tiempo— es lo que permite que el recolector de basura de .NET sea, en la práctica, muy eficiente sin intervención manual del programador.

El recolector de basura resuelve la memoria gestionada (los objetos .NET del montón), pero hay recursos que .NET no puede liberar solo con recolectar memoria: un fichero abierto por el sistema operativo, una conexión de red o de base de datos —recursos no gestionados—. IDisposable, ya presentado en la lección de E/S de Archivos (Módulo 5), es el contrato que esos tipos implementan para liberar ese recurso de forma determinista, es decir, en un momento exacto y predecible, en vez de esperar a que el GC decida actuar (que podría tardar un tiempo indeterminado, dejando el fichero o la conexión abiertos mientras tanto):

La regla práctica fijada entonces sigue vigente sin cambios: cualquier objeto que implemente IDisposable se declara con using (o using var), sin excepciones —StreamReader, SqliteConnection, BibliotecaDbContext (Módulo 5) y, como se verá en el apartado 7, cualquier clase propia que envuelva un recurso no gestionado.

La lección de Constructores y Destructores (Módulo 3) introdujo el finalizador (~Libro()) como un método que el GC invoca antes de liberar un objeto, y adelantó que hoy en día se prefiere IDisposable por su liberación determinista. Ahora que se conocen ambos mecanismos con más profundidad, se pueden combinar en el patrón completo que Microsoft recomienda para cualquier clase que administre un recurso no gestionado directamente:

Cada pieza cumple un papel concreto:

En la práctica, la inmensa mayoría de clases que implementan IDisposable en C# moderno no necesitan un finalizador propio: basta con Dispose() cuando la clase solo posee otros objetos IDisposable ya gestionados (como SqliteConnection), delegando en ellos la parte más delicada. El finalizador completo solo es necesario cuando la clase gestiona directamente un recurso no administrado por ningún otro objeto IDisposable intermedio —un caso menos habitual, pero importante de reconocer si aparece en código existente.

.NET expone GC.Collect(), que fuerza una recolección de basura inmediata. Es tentador pensar que llamarlo "ayuda" al rendimiento, pero en la inmensa mayoría de casos consigue justo lo contrario:

• El recolector de basura ya decide, con su propia heurística de generaciones, cuándo es el momento más eficiente de recolectar; forzarlo manualmente suele interrumpir esa heurística en un momento subóptimo.
• Una recolección completa (generación 2) es la más costosa de las tres; llamarla con frecuencia desde código de aplicación puede degradar el rendimiento en vez de mejorarlo.
• GC.Collect() no libera recursos no gestionados (ficheros, conexiones): eso sigue siendo responsabilidad exclusiva de IDisposable/using, no del recolector de basura.

Los únicos escenarios donde GC.Collect() tiene una justificación real son muy específicos (por ejemplo, inmediatamente después de liberar una cantidad enorme y puntual de memoria, en una herramienta de diagnóstico, o en pruebas de rendimiento que miden el propio comportamiento del GC) y quedan fuera del alcance de este curso. La regla general para BiblioTech y cualquier aplicación normal: confía en el recolector de basura automático y concéntrate en liberar correctamente, con using, los recursos no gestionados —eso sí está bajo tu control directo.

Aunque el GC libera automáticamente la memoria gestionada, en C# es perfectamente posible sufrir una fuga de memoria (objetos que deberían poder liberarse pero que nunca se liberan): la causa más común es una suscripción a un evento que nunca se desuscribe. La lección de Delegados y Eventos (Módulo 4) definió Biblioteca.PrestamoRegistrado:

El problema: mientras biblioteca.PrestamoRegistrado mantenga esa suscripción (biblioteca.PrestamoRegistrado += MostrarAviso), biblioteca conserva internamente una referencia al objeto PanelDeNotificaciones suscrito —a través del delegado apuntando a MostrarAviso—. Si el código de la aplicación descarta su propia referencia a un PanelDeNotificaciones concreto (por ejemplo, al cerrar una ventana en una futura aplicación de escritorio, Módulo 7) sin desuscribirlo primero, ese PanelDeNotificaciones sigue vivo —inalcanzable para el resto del programa, pero referenciado por biblioteca—, y el recolector de basura nunca podrá liberarlo mientras biblioteca siga viva. Si Biblioteca es una instancia de larga vida (como suele serlo, durante toda la ejecución de la aplicación) y se crean muchos PanelDeNotificaciones a lo largo del tiempo sin desuscribirlos nunca, la memoria ocupada por paneles ya "descartados" crece sin límite: una fuga de memoria clásica en aplicaciones C# con eventos, mucho más habitual de lo que parece a primera vista.

Convertir PanelDeNotificaciones también en IDisposable, con -= en su Dispose(), resuelve el problema: al desuscribirse explícitamente, biblioteca deja de mantener ninguna referencia a ese panel concreto, y el GC puede liberarlo con normalidad en cuanto el resto del programa deje de usarlo. La regla general: cualquier suscripción a un evento de larga vida debe tener su -= correspondiente en algún punto del ciclo de vida del suscriptor, igual que todo Open() necesita su Dispose().

Uniendo el patrón del apartado 4 con SqliteConnection (Módulo 5), así queda una clase propia de BiblioTech que envuelve la conexión y garantiza su liberación:

RepositorioSqlite es, en sí mismo, un IDisposable que posee otro IDisposable (_conexion): un caso donde, en la práctica, bastaría con Dispose() sin finalizador (porque SqliteConnection ya tiene su propio finalizador de respaldo). Se muestra aquí el patrón completo, con finalizador incluido, precisamente para dejar visible la estructura entera —la misma que usan internamente clases del propio .NET como SqliteConnection— y que sepas reconocerla si la encuentras en código de terceros.

• Olvidar using sobre un IDisposable propio o ajeno: sin using, el recurso no gestionado (fichero, conexión) permanece abierto hasta que el finalizador se ejecute —en un momento indeterminado, decidido por el GC, no por el programador—, lo que puede agotar recursos del sistema operativo bajo carga.
• Suscribirse a un evento de larga vida sin desuscribirse nunca: como se ha visto con PrestamoRegistrado, es la causa más común de fugas de memoria en aplicaciones C#; toda suscripción += de larga duración necesita su -= correspondiente.
• Añadir un finalizador a una clase que no gestiona directamente ningún recurso no gestionado: un finalizador tiene coste (el GC necesita al menos dos ciclos de recolección para liberar del todo un objeto con finalizador); si la clase solo posee otros IDisposable ya gestionados, basta con Dispose(), sin finalizador propio.
• Llamar a GC.Collect() pensando que "limpia" recursos no gestionados: no lo hace; solo actúa sobre memoria gestionada, y en la mayoría de aplicaciones normales empeora el rendimiento en vez de mejorarlo.
• Consejo: para detectar fugas de memoria por eventos no desuscritos en una aplicación real, las herramientas de perfilado de memoria (memory profilers) permiten ver qué objetos siguen vivos y por qué cadena de referencias —a menudo, la respuesta es exactamente un delegado de evento olvidado.

1. Explica, en un párrafo breve, la diferencia entre la pila y el montón, y en cuál de las dos zonas vive el objeto Libro creado por Libro libro1 = new Libro("Rayuela", "Julio Cortazar", "978-84-376-0495-4"); frente a la variable libro1 en sí.

2. Escribe una clase ConexionSimulada : IDisposable con un campo bool _abierta = true y un método Dispose() que ponga _abierta a false e imprima "Conexion cerrada.". Úsala con using dentro de un bloque y comprueba, tras el bloque, que la conexión ya no está abierta.

3. Retomando PanelDeNotificaciones del apartado 6: escribe una versión de esa clase que implemente IDisposable y se desuscriba correctamente de Biblioteca.PrestamoRegistrado en su Dispose(). Suscríbela, registra un préstamo con RegistrarPrestamo(...) (Módulo 4) para comprobar que recibe el aviso, llama a Dispose(), y registra un segundo préstamo comprobando que ya no se muestra ningún aviso.

La pila almacena variables locales de vida corta, ligadas al método que las declara —incluida la referencia libro1, que no es más que una dirección de memoria—; se libera automáticamente al salir del método. El montón almacena los objetos en sí, creados con new —aquí, el objeto Libro con sus propiedades Titulo, Autor, Isbn—; ese objeto vive en el montón hasta que el recolector de basura determina que ya no hay ninguna referencia accesible hacia él desde el programa.

class ConexionSimulada : IDisposable
{
    private bool _abierta = true;

    public bool EstaAbierta => _abierta;

    public void Dispose()
    {
        _abierta = false;
        Console.WriteLine("Conexion cerrada.");
    }
}

ConexionSimulada? referenciaExterna;
using (ConexionSimulada conexion = new ConexionSimulada())
{
    referenciaExterna = conexion;
    Console.WriteLine(conexion.EstaAbierta); // True
} // Dispose() se llama aqui automaticamente

Console.WriteLine(referenciaExterna.EstaAbierta); // False

class PanelDeNotificaciones : IDisposable
{
    private readonly Biblioteca _biblioteca;

    public PanelDeNotificaciones(Biblioteca biblioteca)
    {
        _biblioteca = biblioteca;
        _biblioteca.PrestamoRegistrado += MostrarAviso;
    }

    private void MostrarAviso(Prestamo prestamo)
    {
        Console.WriteLine($"Nuevo prestamo: {prestamo.Libro.Titulo}");
    }

    public void Dispose()
    {
        _biblioteca.PrestamoRegistrado -= MostrarAviso;
    }
}

Biblioteca biblioteca = new Biblioteca();
Libro libro1 = new Libro("Rayuela", "Julio Cortazar", "978-84-376-0495-4");
Socio socio1 = new Socio(1, "Ana Martinez");
biblioteca.AgregarMaterial(libro1);
biblioteca.AgregarSocio(socio1);

PanelDeNotificaciones panel = new PanelDeNotificaciones(biblioteca);

libro1.Prestar();
biblioteca.RegistrarPrestamo(new Prestamo(libro1, socio1)); // el panel muestra el aviso

panel.Dispose(); // desuscripcion explicita

Libro libro2 = new Libro("Ficciones", "Jorge Luis Borges", "978-84-376-0496-1");
biblioteca.AgregarMaterial(libro2);
libro2.Prestar();
biblioteca.RegistrarPrestamo(new Prestamo(libro2, socio1)); // ya no se muestra ningun aviso

En esta lección has visto cómo gestiona .NET la memoria: la diferencia entre pila y montón, cómo el recolector de basura organiza los objetos en generaciones para recolectar de forma eficiente, y por qué casi nunca conviene llamar a GC.Collect() manualmente. También has completado el patrón IDisposable/finalizador iniciado en el Módulo 3, aplicado sobre una conexión SQLite de BiblioTech, y has visto una fuente muy real de fugas de memoria en C#: los eventos suscritos que nunca se desuscriben, con PrestamoRegistrado como ejemplo concreto.

La última lección de este módulo, Multihilo y Programación Paralela, cambia de plano: en vez de memoria, se ocupa de tiempo de CPU. Retoma la asincronía del Módulo 4 (async/await, pensada para esperar E/S sin bloquear) y la contrasta con el paralelismo real —varios hilos de CPU trabajando literalmente a la vez—, con Thread, Task.Run, Parallel.For/Parallel.ForEach y las técnicas necesarias para proteger datos compartidos entre hilos, cerrando así el Módulo 6 antes de pasar, en el Módulo 7, a construir por fin una interfaz para BiblioTech.