c# event unsubscribe: Practical Usage and Code Examples

c# event unsubscribe requires a clear understanding of the core syntax, runtime behavior, and practical implementation patterns demonstrated in the examples below.

In C#, events are built on delegates. When you subscribe with +=, you add a method reference to the publisher's invocation list. Unsubscribing with -= removes that reference. If you forget to unsubscribe, the publisher keeps a strong reference to the subscriber, which can prevent garbage collection and cause memory leaks. This article covers the syntax, the pitfalls, and the patterns for safely unsubscribing from C# events.

Why Unsubscribing Matters

Every += subscription creates a strong reference from the publisher to the subscriber. As long as the publisher is alive, the subscriber cannot be collected, even if the subscriber is no longer needed. This is a common source of memory leaks in desktop, web, and service applications.

Consider a UI window that subscribes to a background service's event. If the window is closed but the service still holds a reference to the window's handler, the window remains in memory. Over time, repeated open/close cycles accumulate unreachable objects, increasing memory pressure and degrading performance.

Unsubscribing with -= breaks that reference, allowing the subscriber to be garbage collected when no other references exist.

Basic Syntax: Using -= to Unsubscribe

The -= operator removes a handler from an event. The compiler translates it to a call to remove_EventName, which removes the delegate from the invocation list.

public class Publisher
{
    public event EventHandler? SomethingHappened;
}

public class Subscriber
{
    public void HandleEvent(object? sender, EventArgs e)
    {
        Console.WriteLine("Handled");
    }
}

// Usage
var publisher = new Publisher();
var subscriber = new Subscriber();

publisher.SomethingHappened += subscriber.HandleEvent;
// ... later
publisher.SomethingHappened -= subscriber.HandleEvent;

The handler must match the delegate signature exactly. For EventHandler, the method must accept object? sender and EventArgs e. If you use a lambda or an anonymous method, you need a reference to that delegate to remove it.

Unsubscribing from Anonymous Methods and Lambdas

When you subscribe with a lambda, you cannot unsubscribe with the same lambda syntax because each lambda expression creates a new delegate instance. You must store the delegate in a variable and use that variable for both subscription and unsubscription.

EventHandler handler = (sender, e) => Console.WriteLine("Handled");

publisher.SomethingHappened += handler;
// ... later
publisher.SomethingHappened -= handler;

If you need to unsubscribe inside the handler itself, you can capture the delegate variable, but be careful about initialization order.

EventHandler? handler = null;
handler = (sender, e) =>
{
    Console.WriteLine("Handled");
    publisher.SomethingHappened -= handler;
};
publisher.SomethingHappened += handler;

Here, handler is assigned before the lambda runs, so the lambda can reference it. This pattern is useful for one-time event handling.

Handling Multiple Subscriptions and Null References

An event can have multiple subscribers. Unsubscribing with -= removes only the last matching delegate in the invocation list. If the same method is subscribed multiple times, each += adds a separate entry, and each -= removes one occurrence.

publisher.SomethingHappened += subscriber.HandleEvent;
publisher.SomethingHappened += subscriber.HandleEvent;
// Invocation list now has two entries.

publisher.SomethingHappened -= subscriber.HandleEvent;
// Removes one entry; the handler is still subscribed.

If you attempt to unsubscribe a handler that was never added, the operation is a no-op and does not throw. This is safe, but it can mask logic errors if you expect the handler to be present.

For custom events, you can implement explicit add and remove accessors to control the underlying storage. The default event field uses a delegate field that is null when no subscribers exist. The ?.Invoke pattern is used to raise the event safely.

Memory Leaks: When Unsubscription Is Critical

Memory leaks occur when a publisher outlives the subscriber and the subscriber is no longer needed. Common scenarios include:

Static events: A static publisher lives for the entire process, so any subscriber is retained forever unless unsubscribed.
Long-lived services: A service that raises events and holds subscribers can keep UI components or temporary objects alive.
Timer events: Subscribing to System.Timers.Timer.Elapsed without unsubscribing keeps the timer's target alive.

In these cases, unsubscribing is not optional; it is required for correct memory behavior. The cost of a missed -= is not immediate but accumulates over time.

Weak Event Patterns for Long-Lived Publishers

When a publisher is long-lived and subscribers are short-lived, manual unsubscription is error-prone. The weak event pattern allows the publisher to hold a weak reference to the subscriber, so the subscriber can be collected even if it forgets to unsubscribe.

.NET provides WeakEventManager in WPF and WeakEvent<T> in newer versions, but implementing a simple weak event is instructive.

public class WeakEventPublisher
{
    private readonly List<WeakReference> _handlers = new();

    public event EventHandler? SomethingHappened
    {
        add => _handlers.Add(new WeakReference(value));
        remove => _handlers.RemoveAll(wr => wr.Target == value);
    }

    protected void RaiseEvent()
    {
        foreach (var weakRef in _handlers.ToList())
        {
            if (weakRef.Target is EventHandler handler)
                handler(this, EventArgs.Empty);
            else
                _handlers.Remove(weakRef);
        }
    }
}

This implementation removes dead references during raising. It avoids strong references, but it introduces complexity and does not guarantee immediate cleanup. Use it when the publisher's lifetime is significantly longer than the subscribers' and manual unsubscription is not reliably enforced.

Lifecycle Management: When to Unsubscribe

Decide where to unsubscribe based on the subscriber's lifecycle. For UI elements, unsubscribe in the Dispose method or the Closed event. For services, unsubscribe when the consumer is no longer active.

public class Subscriber : IDisposable
{
    private readonly Publisher _publisher;

    public Subscriber(Publisher publisher)
    {
        _publisher = publisher;
        _publisher.SomethingHappened += HandleEvent;
    }

    public void Dispose()
    {
        _publisher.SomethingHappened -= HandleEvent;
    }

    private void HandleEvent(object? sender, EventArgs e) { }
}

Implementing IDisposable makes the unsubscription explicit and testable. In async or short-lived scopes, consider using try/finally to guarantee removal even if an exception occurs.

Common Mistakes and Edge Cases

One frequent mistake is subscribing with a lambda and trying to unsubscribe with the same lambda text. This does not compile because the lambda creates a new delegate each time. Another mistake is unsubscribing in the wrong order, such as removing a handler before it is added, which silently does nothing.

When an event is raised on a different thread, unsubscription can race with invocation. The default event implementation is not thread-safe for concurrent += and -= operations. If you need thread safety, use a lock around the subscription and unsubscription, or use Interlocked operations on the backing delegate field.

For custom events, you can implement thread-safe accessors:

private EventHandler? _somethingHappened;
private readonly object _lock = new();

public event EventHandler? SomethingHappened
{
    add { lock (_lock) { _somethingHappened += value; } }
    remove { lock (_lock) { _somethingHappened -= value; } }
}

This ensures that concurrent subscriptions and unsubscriptions do not corrupt the delegate chain, though the invocation itself still needs a snapshot to avoid races.

Finally, remember that unsubscribing does not throw if the handler is not present. If you rely on a handler being removed, verify the subscription logic rather than assuming -= will fail loudly. Using a debug assertion or a custom event accessor that tracks subscriptions can help catch logic errors early.