Did you have the learning moments

Why unsubscribing from events is overrated.

Do you have any idea what is in almost every article on the subject Memory leak occurs in .NET? It's logging out of events. Now I'm with Stack overflow Stumbled upon a statement from C # authority Jon Skeet that puzzled me:

However, in my experience this is rarely actually a problem - because typically I find that the publisher and subscriber have roughly equal lifetimes anyway. It is a possible cause ... but in my experience it’s rather over-hyped. Your mileage may vary, of course ... you just need to be careful. -Jon Skeet

In addition, with anonymous methods, Lambda expressions, ... C # has been expanded to include constructs that are not that easy to log off. So is this all just hype as Jon Skeet says? As is so often the case, the answer is: it depends.

In this context, it is important to consider what one is Memory leak is. Because managed .NET runs in a sandbox, there is no Memory holes that last the life of an application. You have a Memory leak in your application, if objects are not from the Garbage collector cleared away that you would have expected. The point is that your .NET application needs an unnecessarily large amount of memory during its execution.

Now back to unsubscribing from events. It is clear from the quote that Jon is talking about that Publisher and Subscriber have a similarly high life expectancy. This is often the case with surfaces, for example. You report an object for one Button click at. This object will now exist for about as long as the button. Even if the object could be cleared away much sooner, the question is still how big is the potential "Memory Leak" which arises from it is.

It looks different when you have to deal with long life cycles. By this I mean both the lifespan of the application and the lifespan of the Publishers one Events. If you have an application that continuously consumes memory for days, weeks or months, this can be problematic.

The main question you should ask yourself in this context is, is he alive? Publisher considerably longer than that Subscriber. This can be the case, for example, when you define a as. Another option is if yours Publisher a Singleton is.

For example, do your classes have one Service, server, manager, repository or controller on behalf and offer Events at? Then you should think about the lifetime of their objects.

In addition to the actual memory consumption, which is sometimes not that problematic for a short-lived application, you can also have a performance problem. Imagine that you are a service have to which continuously new Subscriber for a Event Sign in. Now distribute the Subscriber these Events possibly also to some “sub-objects”.

What is happening? Correctly! It can now quickly happen that the triggering of a Events, thousands more Events entails. All because you are yours Subscriber correctly released (e.g. called up or deleted all other references), but that Event have not signed out.

Several thousand Events you won't usually notice it on a current computer, but if there are more, this will have a negative impact on your performance.

First of all, have fun thinking about whether to cancel your events or not

Jan

Notice

  • A Memory leak or Memory hole in .NET means that objects are not from Garbage collector cleared away that you would have expected.
  • If Publisher and Subscriber have a similar lifespan, then it is not necessary to log out.
  • Durable objects which Events can create not only a memory problem, but also a performance problem, if ephemeral objects differ from the Event do not sign out again.
  • Especially with static event and Singletons With Events you have to be careful.
  • Classes in the name Service, server, manager, repository or controller have and Events are potential sources for Memory holes.

Learning quiz

Use the following questions to consolidate what you have learned today:

  • What does it mean when you have a Memory leak in your .NET application?
  • Why does logging out of Events not necessary / important?
  • When should you Events definitely unsubscribe?

The best thing to do is look at the previous questions tomorrow and then again in a few days and answer them without having read the text beforehand.

additional Information

  • There is no source code for this learning moment.
  • For an example where not only memory but also performance becomes a problem, see this article on Tess Ferrandez's MSDN blog.
  • In this article by Collin Eberhardt you will find a method which you can use to find existing Event references can use. According to WPF guru Josh Smith, an approach that should not be missing.
Did you like this learning moment?
Then register and you will be informed about new learning moments: