Memory and Resource Leaks in .NET Applications

The following is a (quite) short summary of this MSDN article

Firstly, it is of vital importance to understand that a Garbage Collected environment such as Managed .NET is not immune to memory leaks. One of the reasons for this is the fact that .NET's Garbage Collector only disposes objects which are no longer referenced by any other object. Ergo, if an object's reference count does not reach zero because of a dangling reference, the GC won't save us.

On the other hand, when we talk about .NET applications which run on Windows, said applications usually consume Operating System resources (bitmaps, thread handles, critical sections, etc). These should be, ideally, released as soon as they are no longer needed.

The author of the MSDN article mentions a ninja technique to hunt down leaks:

Nevertheless, he prefers using higher level tools, such as these

Usual causes for memory leaks in .NET:
  1. Static references (static state and Singletons). Besides, an undisposed static object which contains or references other objects or resources prevents them from being disposed...
  2. Events whose handlers are not unregistered (-= in C#, RemoveHandler in VB-NET)
  3. Not calling Dispose() for those objects whose class implements IDisposable
  4. Incomplete or defective implementation for IDisposable::Dispose in one of our classes
  5. Bugs in third party libraries used by our project, or in .NET (only consider this after thoroughly proving that our code is clean)
After showing a few examples pf leaks and techniques to solve them using the dotTrace tool, the author mentions a few good practices to prevent introducing leaks:
  1. Every object which creates an object is responsible for its disposal (ideally, using RAII semantics), except when the Factory design pattern is used. In that case, the object which uses the Factory must be the one who disposes of the object either directly or calling the Factory.
  2. Events are the main cause of memory leaks in .NET. Whenever you write code to register them, write code to unregister them.
  3. Always call Dispose for our IDisposable classes, and update them thoroughly when we add resources to our classes' state.

Finally, the author recommends a series of very interesting tools. This is better seen in the original article.

Comments

Post a Comment

Popular posts from this blog

VB.NET: Raise base class events from a derived class

Spanish version / Versión en Español Say we: Have a class we want to divide into subclasses The future base class has events The refactoring leads us to the need of raising an event declared in the base class, from a derived class. When we try to do point 3, we will get a compile error saying that a derived class cannot raise events from a base class. To get around this, we add a protected method in the base class which encapsulates the RaiseEvent call, and call that method from the derived class using MyBase. This way: In the base class (parameters as needed): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub And in the derived class: 'Do stuff 'Raise base class event MyBase.OnMessageGenerated( Me, "Message" ) 'Do more stuff... References: Mark Gilbert post
Keep reading

Apache Kafka - I - High level architecture and concepts

Image
Spanish version / Versión en Español First of all, what is Apache Kafka ? An initial definition for it is "a high-throughput distributed messaging system". Breaking this down a bit: High throughput: One of the main goals of Kafka is to process as much messages per unit of time as possible, in a scalable and fault-tolerant way. For example, LinkedIn , which is where Kafka originated, needs to achieve throughputs in the order of 20 million messages per second and 3 GB of data per second. Distributed messaging system: In a generic distributed system , networked computers work together for a common goal. In Kafka's case, that goal is to send data from points A 1 , A 2 , ... A N , to B 1 , B 2 , ... B M . A common benefit of this kind of system, which is crucial to Kafka's success, is horizontal scalability : the ability to handle higher and higher volumes of data by adding nodes to the system (not to be confused with  vertical scalability , whic
Keep reading

Upgrading Lodash from 3.x to 4.x

Spanish version / Versión en Español There are many breaking changes from version 3.x to 4.x; all changes are detailed in the Lodash changelog . There is also a list of deprecated functions , with a regex you can use to detect usages in your code. However, since it is not an exhaustive list, I will list the changes I encountered when performing my own migration, to help anyone undergoing the same process. Direct renames This section includes functions in which only the name changed, i.e. the arguments and return value are the same. 3.x 4.x contains includes first head rest tail invoke invokeMap padLeft padStart padRight padEnd Direct renames if not using thisArg This section includes functions in which the only change is dropping "thisArg". If you are not using it, you can just rename. If you are using thisArg in 3.x, it can be dropped if you are using iteratee to acce
Keep reading