In C#, historically events and event handlers have been at the core of communication between objects. This has been especially true in applications with user interfaces built on WinForms and WPF. However, a common issue arises from the misuse of events—memory leaks! These leaks occur when event subscribers do not properly unsubscribe, leading to retained references and, subsequently, memory not being freed. Enter weak events in C#!
We’ll be looking at a promising solution to help with this challenge. Weak events allow for the garbage collector to reclaim memory from subscribed objects without requiring explicit unsubscribe actions, and help mitigate the risk of memory leaks. While I still encourage you to focus on proper lifetime management of your objects in your application (this is just good practice and design, after all), weak events in C# can give us some extra protection here!
Memory leaks in event handling primarily stem from persistent references between event publishers and subscribers. In typical scenarios, the publisher holds a strong reference to the subscriber via the event delegate. If the subscriber fails to unsubscribe before it is disposed of, the .NET garbage collector cannot reclaim the subscriber’s memory because the publisher still holds a reference to it.
This situation is particularly problematic in applications with a long lifetime or those that dynamically create and destroy many objects. If we’re used to creating objects with event subscriptions where both the publisher and subscriber exist for the entire lifetime of the application… Not a big deal! And if we are dynamically creating these and the lifetime management is simple… also not a big deal! However, object lifetime management can get complicated fast in bigger applications.
Weak events in C# introduce a mechanism where the event subscription does not prevent the garbage collection of the subscriber, effectively reducing the risk of memory leaks.
Weak events in C# are a design pattern that allows event subscribers to be garbage collected, thus preventing memory leaks. Traditionally this isn’t allowed to happen because the event subscription keeps the object alive and prevents it from being collected — even though nothing else seems to be aware of it!
Weak events in C# are particularly useful in scenarios where the event publisher has a longer lifecycle than the subscriber. By implementing weak events in C#, you can help ensure that subscribers don’t unnecessarily persist in memory just because they’re subscribed to an event. This helps maintain optimal memory usage and application performance… Because nobody wants to deal with memory leaks. Especially in a managed language where we often feel sheltered from this!
WeakReference<T>
plays the magic role in the implementation of our weak events in C#. It holds a reference to an object (the subscriber) without preventing that object from being garbage collected. This means the garbage collector can reclaim the memory of the referenced object if there are no strong references to it. In the context of weak events, WeakReference<T>
allows event handlers to be garbage collected, which is key to preventing memory leaks in applications with complex event handling.
Implementing weak events in C# involves creating a class that manages event subscriptions using WeakReference<T>
, ensuring that event handlers do not prevent the garbage collection of the subscriber.
Here’s a step-by-step guide:
Define the WeakEvent Class – Create a class that holds a list of WeakReference
objects pointing to event handlers.
AddListener Method – When a handler is added, it’s wrapped in a WeakReference
to ensure it doesn’t prevent garbage collection of the subscriber. Additionally, we use a ConditionalWeakTable
to keep a strong reference to the delegate if it has a target, preventing premature garbage collection, particularly important for anonymous methods or lambdas.
RemoveListener Method – This involves removing the handler from the list of listeners. This step is crucial for allowing the garbage collector to reclaim memory, especially when the handler or its target is no longer needed.
Raise Method – This iterates through the list of listeners, invoking those who are still alive. If a target has been collected, it removes the listener from the list, ensuring the class does not hold onto dead references.
Let’s check out an example implementation of how we can do weak events in C#:
public sealed class WeakEvent<TEventArgs>
where TEventArgs : EventArgs
{
private readonly List<WeakReference<EventHandler<TEventArgs>>> _handlers;
private readonly ConditionalWeakTable<object, List<object>> _keepAlive;
public WeakEvent()
{
_handlers = [];
_keepAlive = [];
}
public void Subscribe(EventHandler<TEventArgs>? handler)
{
if (handler == null)
{
return;
}
_handlers.Add(new(handler));
if (handler.Target != null)
{
var delegateList = _keepAlive.GetOrCreateValue(handler.Target);
delegateList.Add(handler);
}
}
public void Ubsubscribe(EventHandler<TEventArgs>? handler)
{
if (handler == null)
{
return;
}
_handlers.RemoveAll(wr =>
wr.TryGetTarget(out var existingHandler) &&
existingHandler == handler);
if (handler.Target != null &&
_keepAlive.TryGetValue(handler.Target, out var delegateList))
{
delegateList.Remove(handler);
}
}
public void Raise(object sender, TEventArgs e)
{
foreach (var weakReference in _handlers.ToList())
{
if (weakReference.TryGetTarget(out var handler))
{
handler(sender, e);
}
else
{
_handlers.Remove(weakReference);
}
}
}
}
The above example provides mechanisms for hooking and unhooking event handlers to our source weak event. We can also call Raise()
to trigger the event and support for dealing with anonymous delegates with our _keepAlive
variable. This helps support anonymous delegates from getting garbage collected when they shouldn’t be!
Here’s an example of how we can leverage our WeakEvent<T>
class with an EventSource
and EventListener
:
var eventSource = new EventSource();
var listener = new EventListener();
eventSource.CustomEvent.Subscribe(listener.OnCustomEvent);
eventSource.TriggerEvent();
eventSource.CustomEvent.Unsubscribe(listener.OnCustomEvent);
Console.ReadLine();
public sealed class EventSource
{
private readonly WeakEvent<EventArgs> _customEvent;
public EventSource()
{
_customEvent = new WeakEvent<EventArgs>();
}
public void Subscribe(EventHandler<TEventArgs>? handler) =>
_customEvent.Subscribe(handler);
public void Unsubscribe(EventHandler<TEventArgs>? handler) =>
_customEvent.Unsubscribe(handler);
public void TriggerEvent() =>
_customEvent .Raise(this, EventArgs.Empty);
}
public sealed class EventListener
{
public void OnCustomEvent(object? sender, EventArgs e)
{
Console.WriteLine("Event received.");
}
}
Now that we’ve seen how we can use weak events in C# (along with why), let’s discuss some best practices:
Understand When to Use Them: Weak events are most beneficial in scenarios where event publishers outlive subscribers, such as in UI applications with multiple temporary views or in long-running applications where event subscriptions dynamically change.
Proper Implementation: Ensure weak events are correctly implemented using WeakReference
or ConditionalWeakTable
to prevent memory leaks while still allowing garbage collection.
Testing and Debugging: Regularly test your application for memory leaks and performance issues related to event handling. Tools like Visual Studio Diagnostic Tools can help identify leaks. Visual Studio 2022 17.9 has support for event handler leaks insights as well!
Balancing Use: While weak events mitigate memory leaks, they introduce complexity. Use them where necessary but avoid overuse where simple event handling suffices.
Weak events in C# are a helpful solution for managing memory efficiently concerning event handlers. This is especially true in complex or dynamic applications where the objects’ lifetimes are changing. By allowing subscribers to be garbage collected, weak events prevent potential memory leaks, thereby enhancing application performance. Their correct use, alongside understanding the scenarios they best apply to, can help you avoid problematic memory issues with your events!
If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube!
Also published here.