L'utilisation de lambdas comme gestionnaire d'événements peut-elle provoquer une fuite de mémoire?

Question

Disons que nous avons la méthode suivante:

private MyObject foo = new MyObject(); 

// and later in the class 

public void PotentialMemoryLeaker(){ 
    int firedCount = 0; 
    foo.AnEvent += (o,e) => { firedCount++;Console.Write(firedCount);}; 
    foo.MethodThatFiresAnEvent(); 
} 

Si la classe avec cette méthode est instancié et la méthode PotentialMemoryLeaker est appelée plusieurs fois, avons-nous une fuite de mémoire?

Y at-il un moyen de décrocher ce gestionnaire d'événements lambda après que nous ayons fini d'appeler MethodThatFiresAnEvent?

Answer 1

Oui, enregistrez-le dans une variable et décrochez-le.

DelegateType evt = (o, e) => { firedCount++; Console.Write(firedCount); }; 
foo.AnEvent += evt; 
foo.MethodThatFiresAnEvent(); 
foo.AnEvent -= evt; 

Et oui, si vous ne le faites pas, vous des fuites mémoire, comme vous accrochez un nouvel objet délégué à chaque fois. Vous remarquerez aussi ceci parce que chaque fois que vous appelez cette méthode, il va déverser sur la console un nombre croissant de lignes (pas seulement un nombre croissant, mais pour un appel à MethodThatFiresAnEvent, il va vider un certain nombre d'éléments, une fois pour chaque méthode anonyme connectée).

Answer 2

Oui de la même manière que les gestionnaires d'événements normaux peuvent provoquer des fuites. Parce que le lambda est réellement changé à:

someobject.SomeEvent +=() => ...; 
someobject.SomeEvent += delegate() { 
    ... 
}; 

// unhook 
Action del =() => ...; 
someobject.SomeEvent += del; 
someobject.SomeEvent -= del; 

Donc, fondamentalement, il est juste avant la main pour ce que nous utilisons dans 2.0 toutes ces années.

Answer 3

Vous ne manquerez pas de mémoire, vous obtiendrez également votre lambda appelé plusieurs fois. Chaque appel de 'PotentialMemoryLeaker' ajoutera une autre copie de lambda à la liste des événements, et chaque copie sera appelée lorsque 'AnEvent' sera renvoyé.

Answer 4

Votre exemple se contente de compiler une classe interne privée nommée par le compilateur (avec field firedCount et une méthode nommée par le compilateur). Chaque appel à PotentialMemoryLeaker crée une nouvelle instance de la classe de fermeture à laquelle foo conserve une référence au moyen d'un délégué à la méthode unique.

Si vous ne référencez pas l'objet entier qui possède PotentialMemoryLeaker, alors tout cela sera collecté. Dans le cas contraire, vous pouvez définir foo null ou la liste de gestionnaire d'événements de foo vide en écrivant ceci:

foreach (var handler in AnEvent.GetInvocationList()) AnEvent -= handler; 

Bien sûr, vous aurez besoin d'accès aux membres privés de la MyObject classe.

Answer 5

Eh bien, vous pouvez prolonger ce qui a été fait pour rendre les délégués here plus sûrs à utiliser (pas de fuites de mémoire)