#201 – You Can Leak Memory in C#

In C#, you don’t need to explicitly free memory allocated by creating objects on the heap.  The objects will be automatically garbage collected when no longer referenced.  This means that you won’t experience memory leaks due to forgetting to delete an object.

You can, however, still leak memory in C#.  This can happen if you create one or more new objects on the heap and refer to them from a variable that never goes out of scope during the application’s lifetime.

        public static List<Person> userLog;

        static void RecordUserInfo(Person justLoggedIn)

Here we’re adding to a list of Person objects whenever the RecordUserInfo method is called (presumably when someone logs in).  Assuming that we never remove someone from this list, none of the Person objects added to the list will ever get garbage collected–because we’ll continue to reference them indefinitely.  We’re leaking memory.


Note: This is a different sort of “leak” than you’ll encounter in unmanaged (e.g. C++) code.  In unmanaged code, we often speak of a “leak” as a situation where the application allocates some memory and then gets rid of the reference to that memory.  The application can no longer reclaim the memory.  Managed code doesn’t leak memory in this way because the garbage collector releases resources that are no longer referenced.  However, it’s still possible for an application to allocate memory continuously while running and not release the memory.  If this is not the intent of the developer or required behavior for the application, then it is a bug.  It is also a “leak” in the sense that memory is continuing to be allocated but not released.  It’s not the case that the application can’t release memory but rather than it won’t release memory.  We might pedantically insist that this isn’t technically a memory leak, based on the definition of a traditional leak in unmanaged code.  But from a user’s point of view, the application is leaking memory.  It is unnecessarily allocating memory that it isn’t using.  Worse, it’s doing so in a way that will cause the application’s memory footprint to grow in an unbounded fashion.  This will eventually lead to some sort of out of memory condition.  In practice, people refer to both situations as leaks–the traditional unmanaged leak and the more subtle situation where the application just continues to allocate memory (see The best memory leak definition).  It’s useful to adopt the broader definition of the term “leak”, rather than to say that “C# doesn’t leak memory”, which then leads developers to not think about how the application is allocating and releasing memory.



About Sean
Software developer in the Twin Cities area, passionate about software development and sailing.

6 Responses to #201 – You Can Leak Memory in C#

  1. kai zhou says:

    Usually we don’t use an in-memory list to do the logging, that’s because the logs will get longer and longer(and also because we need to check the logs after the program restarts).

  2. Sean, Thank you Sean for your great posts.

    I’ll disagree on this one: memory leak condition occurs when memory is allocated but ‘cannot’ be freed! This typically happens when the objects becomes unreachable! The example above is an out-of-memory condition! Allocated memory still reachable and can be freed by the application.

    In .NET, even unreachable objects will be reclaimed by the GC.

    Memory leak may occur in the un-managed heap though.

    • Sean says:

      I’ll respectfully disagree. :O) I’ve worked on apps that were “leaking memory” because of a situation like what I show in this post. The application CAN free memory for objects it’s no longer using, but it wasn’t freeing. So the longer the app ran, the more memory was consumed. Maybe just arguing over semantics, but that’s a leak in my mind. Leaks in unmanaged code are possible too, of course.

      • Thank you Sean for your comment. I agree that the argument is around the meaning of the word ‘leak’! Wikipedia defines it as: ” … a memory leak may happen when an object is stored in memory but ‘cannot’ be accessed by the running code”.

  3. Yume says:

    Hello, Sean I am a C# beginner, I just realized I do the above alot on my code. How would you change the code so that there won’t be a memory leak? Thank you

    • Sean says:


      If you have a case where you’re adding elements to a collection but never removing them, then you’d consider removing elements from the collection when the information is no longer needed. In the example above, the implication is that we’re adding to a data structure when someone logs in, but not removing the item when they log out.

      But it depends on what you want to accomplish. You might argue that you do want a data structure that continues to be added to when people are logging in. You then just need to be aware that the memory that your application is consuming will continue to grow during the life of the application–and that’s typically not what you want.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: