Dois-je toujours débrancher de gestionnaires d'événements dans la méthode dispose?

Je travaille en C# et mon lieu de travail a certaines normes du code. L'un d'eux est que chaque gestionnaire d'événement nous connecter (comme KeyDown) doit être déconnecté de l' Dispose méthode. Est-il une bonne raison pour que?

  • Il a certainement un sens si les événements sont static, parce que sinon, le gestionnaire de référence serviront à la racine de l'objet et de prévenir la GC.
  • Cela ressemble à un cas où quelqu'un a eu une fuite de mémoire causées par ailleurs un code incorrect, fait remonter le problème à un gestionnaire d'événements de fuite, et a décidé d'écrire et de faire respecter un code standard, que tous les gestionnaires d'événements doit être déconnecté de l' Dispose méthode. En d'autres termes, au lieu de réellement le travail consiste à comprendre ce qui a causé le problème dans ce cas précis, ils ont décidé de faire plus de travail pour tout le monde everafter. Un pervers de la forme de la cargaison-culte de la programmation, à l'exception d'un seul, le boss peut infliger.
  • Ne sais pas comment dans les dernières versions de .NET, mais sur la 2.0 et 3.5, nous avions fait des problèmes sur le non événement statique abonnements, whe utilisation massive amounf des objets, ou fréquemment utilisées. Semblait comme si que GC n'était pas en mesure de comprendre les liens morts et la mémoire des pompes. Répéter, n'ont pas une preuve scientifique, mais certains monde réel pratiquer, s'est réuni et a confirmé également par les autres membres de la communauté.
  • vous avez absolument raison, il y avait fuite de mémoire juste avant qu'ils ont commencé l'application de cette norme
  • Outre l'échec lamentable de .NET languages pour en faciliter l'utilisation, est-il une raison pourquoi les cas de désinscription ne devrait pas être fait comme une question de cours? Si par exemple un contrôle souscrit à certains événements de la mère et de ne pas annuler l'inscription, que le contrôle est en supposant que le nombre d'instances qui seront créés au cours du parent à la durée de vie sera limitée. Si un parent périodiquement crée et détruit des contrôles enfants, qui pourrait entraîner une surabondance de fuite de mémoire. La manipulation de l'événement de nettoyage constante devrait être plus facile que d'essayer d'identifier les cas qui ne manquera pas sans elle.
InformationsquelleAutor No Idea For Name | 2013-07-01
  1. 70

    À moins que l'éditeur de l'événement à survivre à l'abonné, il n'y a aucune raison de supprimer le gestionnaire d'événements, no.

    C'est un de ces sujets où folk lore a grandi. Vous avez vraiment besoin de penser à ce sujet dans des conditions normales: l'éditeur (par exemple, le bouton) a une référence à l'abonné. Si l'éditeur et l'abonné seront éligibles pour la collecte des ordures dans le même temps de toute façon (comme souvent) ou si l'éditeur seront éligibles pour la collecte des ordures plus tôt, alors il n'y a pas de GC question.

    Statique événements provoquent un GC problème car ils sont en fait une infinité de-longue durée de vie de l'éditeur - je voudrais décourager les événements statiques entièrement, lorsque cela est possible. (J'ai très rarement les trouver utiles.)

    L'autre problème possible est que si vous souhaitez explicitement pour arrêter l'écoute pour des événements parce que votre objet ne se conduisent mal, si l'événement est déclenché (par exemple, il va essayer d'écrire à un flux de données). Dans ce cas, oui, vous devez supprimer le gestionnaire. Qui est plus susceptible d'être dans le cas où votre classe implémente IDisposable déjà. Il serait inhabituel - mais pas impossible - pour justifier la mise en œuvre de IDisposable juste à supprimer des gestionnaires d'événements.

    • J'ai trouvé que dans le jeu de programmation statique des classes d'événements ou des éditeurs qui vivent plus longtemps que les abonnés sont communs.
    • C'est peut-être une question de mauvaise conception, plutôt que ce soit inhérent au problème...
    • Un cas d'utilisation typique peut être que vous les niveaux de charge dans et hors de la mémoire comme le jeu progresse, mais chaque niveau doit être capable d'émettre certains événements du jeu-cadre ou d'autres sous-systèmes qui ont des durées différentes.
    • Ce n'est pas quelque chose que j'avais utiliser des événements pour...
    • Je ne veux pas dire des événements qui sont statiques eux-mêmes, mais les classes qui sont soit en statique ou en avoir qu'une seule instance qui vit pour la durée de vie du jeu.
    • Les classes statiques rarement de bonne qualité appropriées pour que soit. Mais je ne pense pas qu'il y a beaucoup de point en continuant ce dans les commentaires.
    • Je sais que c'est un de six mois de la conversation, mais je veux juste mentionner ici: l'Injection de Dépendance. Qu'est ce que vous voulez. Je comprends pourquoi vous pensez que les classes statiques, les singletons, etc. si nécessaire, la programmation de jeux vidéo est embourbé dans cette réflexion, mais il ya de meilleures façons.

    InformationsquelleAutor Jon Skeet
  2. 11

    J'ai eu un grand GDI fuite dans ma demande si je n'ai pas annuler l'enregistrement des gestionnaires d'événements dans l'Dispose() d'un contrôle utilisateur qui a été créé de façon dynamique et détruit. J'ai trouvé ce qui suit dans le Visual Studio 2013 de l'aide, dans le Guide de Programmation C#. Notez les choses que j'ai mis en italique:

    Comment faire: s'Abonner et de se Désabonner à partir d'Événements

    ...snip...

    Désabonnement

    Pour éviter que votre gestionnaire d'événement d'être appelée lorsque l'événement est déclenché, le désabonnement de l'événement. Afin de prévenir les fuites de ressource, vous devez vous désabonner à partir d'événements avant de vous débarrasser d'un objet de l'abonné. Jusqu'à ce que vous désabonner à partir d'un événement, le délégué multicast qui sous-tend l'événement dans l'édition de l'objet a une référence au délégué qui encapsule l'abonné du gestionnaire d'événement. Tant que la publication de l'objet qui détient de référence, la collecte des ordures ne supprimera pas votre objet de l'abonné.

    Noter que dans mon cas, l'éditeur et l'abonné ont été dans la même classe, et les gestionnaires ne sont pas statiques.

    InformationsquelleAutor JonP