Dealing with Memory Leaks in .NET
Fabrice Marguerie, a software architect and consultant, wrote the article How to detect and avoid memory and resources leaks in .NET applications, published on MSDN. The article explains how memory and resource leaks can happen while programming for .NET and how to avoid them.
Languages like C#, doing house cleaning through a memory garbage collector, do not have memory leaks in its original sense when a program loses complete access to a memory location. According to Fabrice, memory leaks take place when a memory location is no longer needed but the program continues to keep at least one reference to it. The garbage collector would reclaim that memory if it was unreachable, but the memory becomes a leak as long as it is referenced by the program but not used.
Fabrice also lists a number of OS resources which can be subject to similar leaks:
- The system uses User objects to support window management. They include: Accelerator tables, Carets, Cursors, Hooks, Icons, Menus and Windows.
- GDI objects support graphics: Bitmaps, Brushes, Device Contexts (DC), Fonts, Memory DCs, Metafiles, Palettes, Pens, Regions, etc.
- Kernel objects support memory management, process execution, and inter-process communications (IPC): Files, Processes, Threads, Semaphores, Timers, Access tokens, Sockets, etc.
These resources are limited, the registry keys GDIProcessHandleQuota and USERProcessHandleQuota containing the maximum number of GDI and user objects a process can use. The default values are 10,000 for these handles. While the number is enough for most applications, using too many of them will make the system reach another limit of 65,536 handles for a Windows session. Fabrice reported hitting that limit a lot sooner, at about 11,000. His conclusion is that systems resources need to be carefully used and freed when no longer needed.
Fabrice lists the following root causes for leaks explaining how each of them works:
- Using static references
- Event with missing unsubscription – these are considered by the author to be the most common source of leaks
- Static event with missing unsubscription
- Not invoking the Dispose method
- Using an incomplete Dispose method
- Misusing BindingSource in Windows Forms
- Not using Remove call on WorkItem/CAB
The author continues the article by offering advice on how to avoid leaks:
- the creator or owner of an object, not its user, is responsible for disposing it
- always unsubscribe an event listener when it is not longer needed; it could be done in Dispose() for safety
- when an object no longer generates events, all its listeners should be removed by assigning null to the object
- when a reference is used by a model and its view, it is recommended to pass a clone of the referenced object to the view to avoid losing track of who’s using what
- calls to system resources should be enclosed in using blocks which automatically force a Dispose call when leaving the block
I would add...
Also, i think no discussion about .NET memory leak (or Java, for that matter) is complete without talking about WeakReferences (references that allow the garbage collector to clean the objects if no other references are found)
Re: I would add...
WeakReferences are covered in the article, even if I just give a hint at them.
Ian Culling, Andy Powell & Lee Cunningham Dec 11, 2013