Since the very first line of code in this course, .NET has automatically managed the memory of every object created with new: you've never had to allocate or free it by hand, as you would in languages like C or C++. That convenience has a mechanism behind it, the garbage collector (GC), and some clear limits: there are resources — files, network or database connections — that the GC does not know how to free on its own, and that depend on the IDisposable/using pattern already seen in Module 5. This lesson explains how the GC works internally, revisits IDisposable in its complete form (the Dispose/finalizer pattern), and exposes a very real source of memory leaks in C#: events with subscribers that never unsubscribe.

1. Stack and heap: where each piece of data lives
2. The garbage collector: generations 0, 1, and 2
3. IDisposable and using/using var: a recap from the File I/O lesson
4. The complete Dispose/finalizer pattern
5. GC.Collect(): why you should almost never call it manually
6. Common memory leaks in C#: unsubscribed events
7. Example: a complete IDisposable over a BiblioTech SQLite connection

.NET allocates memory in two areas with very different lifetime rules:

It's important to distinguish the variable from what it references: Book book1 = new Book(...); stores in the stack a reference (a memory address) pointing to the real Book object, created on the heap by new. When the method ends, that stack reference disappears immediately; the Book object on the heap, by contrast, keeps existing until the garbage collector decides nobody needs it anymore — the topic of the next section. Value types (struct, as seen in the Structs and Records lesson, Module 3) can live entirely on the stack when they're local variables, never touching the heap at all.

.NET's garbage collector automatically frees heap objects that no longer have any reachable reference from the program — that is, ones no longer reachable from any variable in use. To avoid examining the whole heap every time, it organizes objects into three generations, based on an empirical observation: most objects die young (temporary variables inside a method), and the ones that survive tend to live for a long time (the entire Catalog of Library, for example):

When the GC collects generation 0 and finds that an object still has active references, it promotes it to generation 1; if it also survives a generation 1 collection, it moves up to generation 2. This strategy — checking frequently what's probably already dead, and rarely what's probably going to stay alive for a long time — is what lets .NET's garbage collector be, in practice, very efficient with no manual intervention from the programmer.

The garbage collector solves for managed memory (.NET objects on the heap), but there are resources .NET can't free just by collecting memory: a file opened by the operating system, a network or database connection — unmanaged resources. IDisposable, already introduced in the File I/O lesson (Module 5), is the contract those types implement to release that resource deterministically — that is, at an exact, predictable moment, instead of waiting for the GC to decide to act (which could take an indeterminate amount of time, leaving the file or connection open in the meantime):

The practical rule set back then still stands unchanged: any object that implements IDisposable gets declared with using (or using var), no exceptions — StreamReader, SqliteConnection, LibraryDbContext (Module 5), and, as you'll see in section 7, any custom class that wraps an unmanaged resource.

The Constructors and Destructors lesson (Module 3) introduced the finalizer (~Book()) as a method the GC invokes before freeing an object, and noted that IDisposable is nowadays preferred for its deterministic release. Now that both mechanisms are known in more depth, they can be combined into the complete pattern Microsoft recommends for any class that directly manages an unmanaged resource:

Each piece plays a specific role:

In practice, the vast majority of classes implementing IDisposable in modern C# don't need their own finalizer: Dispose() alone is enough when the class only owns other, already-managed IDisposable objects (like SqliteConnection), delegating the trickiest part to them. The full finalizer is only needed when the class directly manages an unmanaged resource with no intermediate IDisposable object handling it — a less common case, but important to recognize if it turns up in existing code.

.NET exposes GC.Collect(), which forces an immediate garbage collection. It's tempting to think that calling it "helps" performance, but in the vast majority of cases it achieves just the opposite:

• The garbage collector already decides, with its own generational heuristics, when is the most efficient time to collect; forcing it manually usually interrupts that heuristic at a suboptimal moment.
• A full collection (generation 2) is the most expensive of the three; calling it frequently from application code can degrade performance instead of improving it.
• GC.Collect() doesn't free unmanaged resources (files, connections): that remains the exclusive responsibility of IDisposable/using, not of the garbage collector.

The only scenarios where GC.Collect() has a real justification are very specific (for instance, immediately after freeing a huge, one-off amount of memory, in a diagnostic tool, or in performance tests that measure the GC's own behavior) and fall outside this course's scope. The general rule for BiblioTech and any normal application: trust the automatic garbage collector and focus on correctly releasing, with using, the unmanaged resources — that's what's actually under your direct control.

Even though the GC automatically frees managed memory, it's entirely possible to suffer a memory leak in C# (objects that should be freeable but never get freed): the most common cause is a subscription to an event that never gets unsubscribed. The Delegates and Events lesson (Module 4) defined Library.LoanRegistered:

The problem: as long as library.LoanRegistered keeps that subscription (library.LoanRegistered += ShowAlert), library internally holds a reference to the subscribed NotificationPanel object — through the delegate pointing to ShowAlert. If the application code discards its own reference to a particular NotificationPanel (for example, on closing a window in a future desktop application, Module 7) without unsubscribing it first, that NotificationPanel stays alive — unreachable from the rest of the program, but still referenced by library — and the garbage collector can never free it as long as library stays alive. If Library is a long-lived instance (as it usually is, for the entire run of the application) and many NotificationPanels get created over time without ever unsubscribing them, the memory taken up by already "discarded" panels grows without bound: a classic memory leak in C# applications with events, much more common than it might seem at first glance.

Turning NotificationPanel into an IDisposable too, with -= in its Dispose(), solves the problem: by unsubscribing explicitly, library stops holding any reference to that particular panel, and the GC can free it normally as soon as the rest of the program stops using it. The general rule: any subscription to a long-lived event must have its matching -= somewhere in the subscriber's lifecycle, just as every Open() needs its Dispose().

Combining the pattern from section 4 with SqliteConnection (Module 5), here's a custom BiblioTech class that wraps the connection and guarantees its release:

SqliteRepository is itself an IDisposable that owns another IDisposable (_connection): a case where, in practice, Dispose() alone would be enough (because SqliteConnection already has its own backup finalizer). The complete pattern is shown here, finalizer included, precisely to keep the full structure visible — the same one used internally by .NET's own classes like SqliteConnection — so you can recognize it if you find it in third-party code.

• Forgetting using on a custom or third-party IDisposable: without using, the unmanaged resource (file, connection) stays open until the finalizer runs — at an indeterminate moment, decided by the GC, not by the programmer — which can exhaust operating system resources under load.
• Subscribing to a long-lived event and never unsubscribing: as seen with LoanRegistered, this is the most common cause of memory leaks in C# applications; every long-lived += subscription needs its matching -=.
• Adding a finalizer to a class that doesn't directly manage any unmanaged resource: a finalizer has a cost (the GC needs at least two collection cycles to fully free an object with a finalizer); if the class only owns other, already-managed IDisposable objects, Dispose() alone is enough, with no finalizer of its own.
• Calling GC.Collect() thinking it "cleans up" unmanaged resources: it doesn't; it only acts on managed memory, and in most normal applications it worsens performance instead of improving it.
• Tip: to detect memory leaks caused by unsubscribed events in a real application, memory profiling tools let you see which objects are still alive and through what chain of references — often, the answer is exactly a forgotten event delegate.

1. Explain, in a short paragraph, the difference between the stack and the heap, and in which of the two areas the Book object created by Book book1 = new Book("Hopscotch", "Julio Cortazar", "978-84-376-0495-4"); lives, versus the book1 variable itself.

2. Write a class SimulatedConnection : IDisposable with a field bool _open = true and a Dispose() method that sets _open to false and prints "Connection closed.". Use it with using inside a block and check, after the block, that the connection is no longer open.

3. Revisiting NotificationPanel from section 6: write a version of that class that implements IDisposable and correctly unsubscribes from Library.LoanRegistered in its Dispose(). Subscribe it, register a loan with RegisterLoan(...) (Module 4) to check that it receives the alert, call Dispose(), and register a second loan checking that no alert is shown anymore.

The stack stores short-lived local variables, tied to the method that declares them — including the reference book1, which is nothing more than a memory address — and it's freed automatically on leaving the method. The heap stores the objects themselves, created with new — here, the Book object with its Title, Author, Isbn properties — and that object lives on the heap until the garbage collector determines there's no longer any reachable reference to it from the program.

class SimulatedConnection : IDisposable
{
    private bool _open = true;

    public bool IsOpen => _open;

    public void Dispose()
    {
        _open = false;
        Console.WriteLine("Connection closed.");
    }
}

SimulatedConnection? externalReference;
using (SimulatedConnection connection = new SimulatedConnection())
{
    externalReference = connection;
    Console.WriteLine(connection.IsOpen); // True
} // Dispose() is called here automatically

Console.WriteLine(externalReference.IsOpen); // False

class NotificationPanel : IDisposable
{
    private readonly Library _library;

    public NotificationPanel(Library library)
    {
        _library = library;
        _library.LoanRegistered += ShowAlert;
    }

    private void ShowAlert(Loan loan)
    {
        Console.WriteLine($"New loan: {loan.Book.Title}");
    }

    public void Dispose()
    {
        _library.LoanRegistered -= ShowAlert;
    }
}

Library library = new Library();
Book book1 = new Book("Hopscotch", "Julio Cortazar", "978-84-376-0495-4");
Member member1 = new Member(1, "Ana Martinez");
library.AddItem(book1);
library.AddMember(member1);

NotificationPanel panel = new NotificationPanel(library);

book1.Lend();
library.RegisterLoan(new Loan(book1, member1)); // the panel shows the alert

panel.Dispose(); // explicit unsubscription

Book book2 = new Book("Ficciones", "Jorge Luis Borges", "978-84-376-0496-1");
library.AddItem(book2);
book2.Lend();
library.RegisterLoan(new Loan(book2, member1)); // no alert is shown anymore

In this lesson you've seen how .NET manages memory: the difference between the stack and the heap, how the garbage collector organizes objects into generations to collect efficiently, and why it's almost never a good idea to call GC.Collect() manually. You've also completed the IDisposable/finalizer pattern started in Module 3, applied over a BiblioTech SQLite connection, and seen a very real source of memory leaks in C#: subscribed events that never get unsubscribed, with LoanRegistered as a concrete example.

The last lesson of this module, Multithreading and Parallel Programming, shifts focus: instead of memory, it deals with CPU time. It picks back up asynchrony from Module 4 (async/await, meant for waiting on I/O without blocking) and contrasts it with real parallelism — several CPU threads working literally at the same time — with Thread, Task.Run, Parallel.For/ Parallel.ForEach, and the techniques needed to protect shared data across threads, closing out Module 6 before moving on, in Module 7, to finally build an interface for BiblioTech.