Quelles sont les règles à suivre lorsque dispose () est requirejs?

Bien que je code depuis un certain temps, je suis vraiment à peine dans ce que j’appellerais un codeur de niveau intermédiaire. Je comprends donc le principe de dispose (), qui consiste à libérer de la mémoire réservée aux variables et / ou aux ressources. J’ai également constaté que, parfois, en utilisant EF, je devais disposer () pour que d’autres opérations fonctionnent correctement. Ce que je ne comprends pas, c’est exactement ce qui nécessite une libération, quand employer dispos ()

Par exemple, nous ne disposons pas de variables telles que chaîne, entier ou booléen. Mais quelque part, nous traversons “une ligne” et les variables et / ou ressources que nous utilisons doivent être éliminées. Je ne comprends pas où se trouve la ligne.

Existe-t-il un seul principe ou quelques principes généraux à appliquer pour savoir quand utiliser élimin ()?

J’ai lu ces messages SO ( une situation spécifique , plus sur comment plutôt que sur quand ) mais je n’ai pas l’impression de comprendre les bases du savoir quand utiliser dispose (). Un commentaire que j’ai vu demandait si la mémoire était libérée quand une variable sortait de la scope, ce qui a attiré mon attention; jusqu’à ce que la réponse soit non, elle ne sera pas publiée simplement parce qu’elle sort de la scope, j’aurais pensé il est libéré quand il sort de la scope. Je ne veux pas être ce qu’une personne dans le 2e lien a appelé un “développeur sans intelligence”, bien que je pensais que c’était un peu dur. Certains d’entre nous apprennent encore.

C’est pourquoi ma question est “Qu’est-ce qui détermine le moment où dispose () est vraiment nécessaire?”

Ma question est moins de savoir comment et plus de quand . Bien sûr, des commentaires sur l’utilité, mais même si la méthode pour appeler dispose () est une instruction Using, il me faut quand même savoir quand.

Modifier à la question initiale: Je sais qu’il s’agit d’une longue explication, car les demandes de commentaires sont en double , et ce n’est pas une impasse, je ne sais pas comment faire pour que ma question soit au centre de la question. Souvent, nous nous contentons de trébucher pour demander quelque chose. Comme je le mentionne à la fin de ce long texte, je modifierai tout cela une fois que nous nous serons concentrés sur mon problème, en supposant que nous y arrivions. D’après ce que j’ai lu, je pense que c’est une question importante.

Le message “réponse” proposé est un excellent message, mais ne répond pas vraiment à ma question. Le commentaire de CodeNotFound ci-dessous donne également un excellent lien, mais il ne répond pas vraiment à ma question non plus. J’ai fourni des commentaires concernant ces articles pour tenter d’affiner ma question précise:

Quand dois-je disposer mes objects dans .NET? : La première réponse commence par un commentaire qui

Les objects jetables sont des objects contenant une ressource précieuse dont le CLR n’est pas insortingnsèquement conscient.

Malheureusement, je ne comprends pas ce que comprend l’expression ” objects jetables … le CLR n’est pas insortingnsèquement consciente “. C’est ce que je demande. Comment savoir si quelque chose entre dans la catégorie de ce que je dois disposer? Nous définissons les choses à utiliser dans le code tout le temps. Quand franchissons-nous la ligne et cela devient un object dont j’ai besoin de disposer ()? BTW, j’ai remarqué l’auteur de ce post n’a jamais marqué une réponse. Je ne sais pas si cela signifie qu’il n’a pas l’impression que la question a été résolue ou s’il s’agissait simplement d’un mauvais suivi de sa part, mais j’espère avoir précisé un peu ce que j’espérais comprendre. Lorsque vous examinez attentivement les réponses, elles ne traitent pas vraiment de la question de savoir quels objects requièrent l’action d’un développeur pour en disposer (), ni comment je pourrais m’y prendre pour savoir comment identifier quels objects. Je ne sais tout simplement pas quels objects ou choses que je crée exigent que je sois responsable de leur élimination. Et je comprends que la GC et d’autres dispositions entrent en jeu, mais encore une fois, c’est juste le comment . Ce qui semble clair, c’est que les développeurs les plus expérimentés et les plus professionnels savent qu’il est nécessaire de se débarrasser de quelque chose qu’ils ont créé. Je ne comprends pas comment savoir ça .

Utilisation correcte de l’interface IDisposable : Clairement une réponse populaire (1681 votes positifs), mais la réponse marquée commence par

Le but de Dispose est de libérer des ressources non gérées “.

OK, mais ma question est de savoir comment savoir si, en regardant quelque chose, il s’agit d’une ressource non gérée . Et je ne comprends pas comment la note qui suit s’applique à ce qui doit être éliminé.

Si vous l’avez trouvé dans le framework .NET, il est géré . Si vous êtes allé fouiller vous-même MSDN, c’est non géré … et vous êtes maintenant responsable de le nettoyer. ”

Je ne comprends pas comment utiliser ce type d’explication pour catégoriser ce dont j’ai besoin de disposer () et ce que je n’ai pas. Il y a toutes sortes de choses dans le framework .net; comment puis-je séparer les choses qui nécessitent que je dispose () d’eux? Qu’est-ce que je regarde pour me dire que j’en suis responsable?

Après cela, la réponse continue de parler longuement de la façon de disposer (), mais je rest bloqué sur ce qui doit être éliminé. Pour compliquer davantage le sujet pour moi, cet auteur dit plus tard “Alors maintenant, nous allons …

se débarrasser des ressources non gérées (parce que nous devons le faire), et

se débarrasser des ressources gérées (parce que nous voulons être utiles)

Alors maintenant, je dois envisager de disposer d’un nouvel ensemble d’objects qui utilisent la mémoire, et je ne sais pas non plus quels sont ces objects. L’auteur de la réponse dit plus tard

Pour ceux qui aiment le style de cette réponse (expliquer le pourquoi, le comment devient alors évident) …

Je comprends que l’auteur suggérait d’autres articles, mais sa suggestion selon laquelle comprendre le “pourquoi” rend le “comment” évident n’est pas vraiment légitime, car ce qui est évident pour une personne ne l’est pas toujours pour une autre. Et même à cela, l’auteur s’est concentré davantage sur le pourquoi et le comment , et ma question concerne le moment , ce qui signifie ce qui doit être éliminé (), par opposition à quand j’en ai fini. Je sais que lorsque j’en ai fini avec les choses, je ne sais tout simplement pas de quoi je suis responsable lorsque j’en ai fini.

Ce qui doit être disposé () peut sembler évident ou instinctif à la plupart des développeurs, mais ce n’est pas évident pour moi et je suis sûr que beaucoup d’autres en sont à mon stade d’expérience et j’espérais avoir un dialog plus ciblé sur quoi . Certes, pourquoi est utile, mais dans ce cas, seulement si le pourquoi est attaché à un quoi . Par exemple: Vous devez disposer d’un DbContext, car le CLR ne le disposera pas, car cela explique pourquoi , mais dans ce cas, c’est le DbContext qui est ce qui doit être éliminé.

J’espérais qu’il existe un principe général concernant ce qu’il faut éliminer plutôt qu’une longue liste d’éléments spécifiques qui ne seraient pas particulièrement utiles pour les personnes comme moi qui recherchent des directives simples.

Encore une fois, je comprends que la libération de la mémoire est importante et que beaucoup d’expérience et de compétences sont nécessaires pour savoir pourquoi et comment , mais je rest néanmoins aux sockets avec des difficultés à comprendre ce qui doit être éliminé. Une fois que je comprends ce que je dois disposer (), je peux alors commencer la lutte pour apprendre à le faire.

Alors, est-ce toujours une mauvaise question? Je relirai toute cette explication plus tard pour que le post soit plus succinct, à supposer que nous puissions nous concentrer davantage sur ce que je demande.

Final Edit: Bien que je l’ai dit plus haut, j’éclaircissais ce que j’imaginais au départ comme un texte inutile dans la question, je pense qu’il est préférable de le laisser. Je pense que la façon dont les questions sont posées peut potentiellement nous aider à comprendre la réponse. Même si la réponse ne change jamais, si nous ne lions pas la réponse à la façon dont nous avons formulé la question dans notre esprit, nous ne pourrons pas vraiment comprendre la réponse. Donc, si la façon dont cette question a été formulée est liée à quelqu’un, je vous encourage à lire intégralement le message marqué comme la réponse, ainsi que les commentaires. Au final, la réponse était très simple, mais il est important de comprendre l’histoire et le contexte pour comprendre la réponse à cette question. Par souci de clarté, la réponse a également été modifiée au cours de la discussion sur la disposition (). Prendre plaisir…

Je comprends le principe de dispose (), qui consiste à libérer de la mémoire réservée aux variables et / ou aux ressources.

Vous ne comprenez pas le but de disposer. Ce n’est pas pour libérer de la mémoire associée aux variables.

Ce que je ne comprends pas, c’est exactement ce qui nécessite une libération, quand employer dispos ().

Éliminez tout ce qui implémente IDisposable lorsque vous êtes certain d’en avoir terminé.

Par exemple, nous ne disposons pas de variables telles que chaîne, entier ou booléen. Mais quelque part, nous traversons “une ligne” et les variables et / ou ressources que nous utilisons doivent être éliminées. Je ne comprends pas où se trouve la ligne.

La ligne est délimitée pour vous. Lorsqu’un object implémente IDisposable, il doit être supprimé.

Je remarque que les variables ne sont pas des objects qui sont éliminés. Les objects sont éliminés. Les objects ne sont pas des variables et les variables ne sont pas des objects. Les variables sont des emplacements de stockage pour les valeurs .

Existe-t-il un seul principe ou quelques principes généraux à appliquer pour savoir quand utiliser élimin ()?

Un seul principe: disposer lorsque l’object est jetable.

Je ne sens pas que je comprends les bases de savoir quand utiliser dispose ().

Éliminez tous les objects jetables.

Un commentaire que j’ai vu demandait si la mémoire était libérée quand une variable sortait de la scope, ce qui a attiré mon attention; jusqu’à ce que la réponse soit non, elle ne se libère pas simplement parce qu’elle sort de la scope, j’aurais pensé que il est libéré quand il sort de la scope.

Soyez prudent dans votre utilisation de la langue. Vous confondez scope et durée de vie et vous confondez des variables avec le contenu des variables.

Premièrement: la scope d’une variable est la région du texte du programme dans laquelle cette variable peut être désignée par son nom . La durée de vie d’une variable est la période de temps pendant l’exécution du programme au cours de laquelle la variable est considérée comme une racine du garbage collector. Scope est purement un concept de compilation, la durée de vie est purement un concept d’exécution.

Le lien entre la scope et la durée de vie est que la durée de vie d’une variable locale commence souvent lorsque le contrôle entre dans la scope de la variable et se termine quand elle la quitte. Cependant, différentes choses peuvent modifier la durée de vie d’un local, notamment le fait d’être fermé, dans un bloc iterator ou dans une méthode asynchrone. L’optimiseur de gigue peut également raccourcir ou prolonger la durée de vie d’un local.

N’oubliez pas non plus qu’une variable est un stockage et qu’elle peut faire référence à un stockage. Lorsque la durée de vie d’un local se termine, le stockage associé au local peut être récupéré. Mais rien ne garantit que le stockage associé à l’élément auquel le local fait référence sera récupéré, à ce moment-là ou jamais.

C’est pourquoi ma question est “Qu’est-ce qui détermine le moment où dispose () est vraiment nécessaire?”

L’élimination est nécessaire lorsque l’object implémente IDisposable. (Il existe un petit nombre d’objects jetables qu’il n’est pas nécessaire de supprimer. Tâches, par exemple. Mais en règle générale, s’il est jetable, supprimez-le.)

Ma question est moins de savoir comment et plus de quand.

Ne jetez une chose que lorsque vous en avez fini. Pas avant et pas plus tard.

Quand dois-je disposer mes objects dans .NET?

Éliminez les objects lorsqu’ils implémentent IDisposable et vous avez fini de les utiliser.

Comment savoir si quelque chose entre dans la catégorie de ce que je dois disposer?

Quand il implémente IDisposable.

Je ne sais tout simplement pas quels objects ou choses que je crée exigent que je sois responsable de leur élimination.

Les jetables.

la plupart des développeurs expérimentés et professionnels savent que quelque chose qu’ils ont créé doit être éliminé. Je ne comprends pas comment savoir ça.

Ils vérifient si l’object est jetable. Si c’est le cas, ils en disposent.

Le but de Dispose est de libérer des ressources non gérées “. OK, mais ma question est de savoir comment puis-je savoir, en regardant quelque chose, qu’il s’agit d’une ressource non gérée?

Il implémente IDisposable.

Je ne comprends pas comment utiliser ce type d’explication pour catégoriser ce dont j’ai besoin de disposer () et ce que je n’ai pas. Il y a toutes sortes de choses dans le framework .net; comment puis-je séparer les choses qui nécessitent que je dispose () d’eux? Qu’est-ce que je regarde pour me dire que j’en suis responsable?

Vérifiez pour voir si c’est IDisposable.

Après cela, la réponse continue de parler longuement de la façon de disposer (), mais je rest bloqué sur ce qui doit être éliminé.

Tout ce qui implémente IDisposable doit être éliminé.

Ma question est de savoir quand, ce qui veut dire ce qui doit être éliminé (), par opposition à quand j’en ai fini. Je sais que lorsque j’en ai fini avec les choses, je ne sais tout simplement pas de quoi je suis responsable lorsque j’en ai fini.

Les choses qui implémentent IDisposable.

J’espérais qu’il existe un principe général concernant ce qu’il faut éliminer plutôt qu’une longue liste d’éléments spécifiques qui ne seraient pas particulièrement utiles pour les personnes comme moi qui recherchent des directives simples.

La ligne direcsortingce simple est que vous devriez disposer des choses jetables.

Encore une fois, je comprends que la libération de la mémoire est importante et que beaucoup d’expérience et de compétences sont nécessaires pour savoir pourquoi et comment, mais je rest néanmoins aux sockets avec des difficultés à comprendre ce qui doit être éliminé. Une fois que je comprends ce que je dois disposer (), je peux alors commencer la lutte pour apprendre à le faire.

Éliminez les éléments qui implémentent IDisposable en appelant Dispose ().

Alors, est-ce toujours une mauvaise question?

C’est une question très répétitive.

Votre patience est une gentillesse.

Merci d’avoir pris cette réponse un peu idiote dans l’humour auquel elle était destinée!

Portée WRT! = Durée de vie et variables! = Objets, très utile.

Celles-ci sont très souvent confondues et la plupart du temps, cela fait peu de différence. Mais je trouve que souvent les personnes qui ont du mal à comprendre un concept ne sont pas du tout servies par le flou et l’imprécision.

Sous VS, c’est aussi simple que de regarder dans Object Browser / Intellisense pour voir si l’object inclut Dispose ()?

La grande majorité du temps, oui.

Il y a des cas obscurs de coin. Comme je l’ai déjà mentionné, l’équipe de TPL a estimé qu’il était non seulement inutile de supprimer des objects de tâche, mais aussi d’être contre-productif.

Certains types implémentent également IDisposable, mais utilisent l’astuce “implémentation d’interface explicite” pour rendre la méthode “Dispose” accessible uniquement par transtypage en IDisposable. Dans la majorité des cas, il existe un synonyme pour Dispose sur l’object lui-même, généralement appelé “Close” ou quelque chose du genre. Je n’aime pas beaucoup ce modèle, mais certaines personnes l’utilisent.

Pour ces objects, le bloc using fonctionnera toujours. Si, pour une raison quelconque, vous souhaitez explicitement supprimer de tels objects sans utiliser using alors (1) appelez la méthode “Close”, ou quoi que ce soit appelé, ou (2) convertissez en IDisposable et supprimez-la.

La sagesse générale est la suivante: si l’object est jetable, il ne fait pas de mal de le jeter, et c’est une bonne pratique de le faire lorsque vous avez terminé.

La raison en est que les objects jetables représentent souvent une ressource partagée rare. Un fichier, par exemple, peut être ouvert dans un mode qui refuse aux autres processus le droit d’accéder à ce fichier pendant son ouverture. C’est la chose polie à faire pour s’assurer que le dossier est fermé dès que vous en avez terminé. Si un processus souhaite utiliser un fichier, les chances sont plutôt bonnes, un autre le sera bientôt.

Ou un object jetable peut représenter quelque chose comme un object graphique. Le système d’exploitation cessera de diffuser de nouveaux objects graphiques s’il y a plus de dix mille actifs dans un processus. Vous devez donc les laisser disparaître lorsque vous avez terminé.

WRT implémentant IDisposable @ Le commentaire de Brian suggère que, dans un codage “normal”, je n’ai probablement pas besoin de le faire. Donc, ne ferais-je cela que si ma classe s’inscrivait dans quelque chose de non géré?

Bonne question. Il existe deux scénarios dans lesquels vous devez implémenter IDisposable.

(1) Le scénario courant: vous écrivez un object qui rest longtemps sur un autre object identifiable, et la durée de vie de l’object “interne” est identique à la durée de vie de l’object “externe”.

Par exemple: vous implémentez une classe de journalisation qui ouvre un fichier journal et le maintient ouvert jusqu’à la fermeture du journal. Maintenant, vous avez une classe qui conserve un jetable, qui devrait donc lui aussi être jetable.

Je remarque qu’il n’est pas nécessaire dans ce cas que l’object “externe” soit finalisable . Juste jetable. Si pour une raison quelconque, la disposition n’est jamais appelée sur l’object extérieur, le finaliseur de l’object intérieur se chargera de la finalisation.

(2) le scénario rare: vous implémentez une nouvelle classe qui demande au système d’exploitation ou à une autre entité externe une ressource devant être nettoyée de manière agressive, et la durée de vie de cette ressource est identique à la durée de vie de l’object qui la conserve. .

Dans ce cas extrêmement rare, vous devriez d’abord vous demander s’il est possible de l’éviter. C’est une mauvaise situation pour un programmeur débutant à intermédiaire. Vous devez vraiment comprendre comment le CLR interagit avec du code non managé afin de rendre ce travail solide.

Si vous ne pouvez pas l’éviter, préférez ne pas essayer d’implémenter vous-même la logique de disposition et de finalisation, notamment si l’object non géré est représenté par un descripteur Windows. Il devrait déjà y avoir des wrappers autour de la plupart des services de système d’exploitation représentés par des handles, mais s’il n’y en a pas, ce que vous voulez faire est d’étudier attentivement la relation entre IntPtr, SafeHandle et HandleRef. IntPtr, SafeHandle et HandleRef – Explained

Si vous avez vraiment besoin d’écrire la logique d’élimination pour une ressource non gérée, sans ressource, et que la ressource nécessite de prendre en charge l’élimination avec la finalisation, vous avez un défi technique de taille.

Le code de modèle de disposition standard peut sembler simple, mais l’écriture d’une logique de finalisation correcte, robuste face aux conditions d’erreur, présente de réelles subtilités. N’oubliez pas qu’un finaliseur s’exécute sur un autre thread et peut s’exécuter sur ce thread en même temps que le constructeur dans des scénarios d’abandon de thread . Écrire une logique threadsafe qui nettoie un object alors qu’il est encore en construction sur un autre thread peut s’avérer extrêmement difficile et je déconseille d’essayer.

Pour plus d’informations sur les défis de la rédaction des finaliseurs, voir ma série d’articles sur le sujet: http://ericlippert.com/2015/05/18/when-everything-you-know-is-wrong-part-one/

Une question que vous n’avez pas posée mais à laquelle je répondrai quand même:

Existe-t-il des scénarios dans lesquels je ne devrais pas implémenter IDisposable?

Oui. De nombreuses personnes implémentent IDisposable chaque fois qu’elles souhaitent avoir un modèle de codage ayant la sémantique de:

  • Faire un changement dans le monde
  • Faire des choses dans le nouveau monde
  • Annuler le changement

Ainsi, par exemple, “empruntez l’identité d’un administrateur, effectuez certaines tâches administratives, revenez à l’utilisateur normal”. Ou “commencez à gérer un événement, faites des choses lorsque l’événement se produit, arrêtez de gérer l’événement”. Ou “créez un outil de suivi des erreurs en mémoire, effectuez des opérations susceptibles de provoquer des erreurs, arrêtez les erreurs de suivi”. Etc. Vous obtenez le modèle général.

Cela convient mal au modèle jetable, mais cela n’empêche pas les gens d’écrire des classes qui ne représentent aucune ressource non gérée, mais qui implémentent quand même IDisposable.

Cette opinion me met dans une minorité; Beaucoup de gens n’ont aucun problème avec cet abus du mécanisme. Mais quand je vois un article jetable, je pense que “l’auteur de cette classe souhaite que je sois poli et que je nettoie après moi même quand je serai bon et prêt “. Mais le contrat actuel de la classe est souvent le suivant: “vous devez disposer de cela à un point particulier du programme et si vous ne le faites pas, le rest de la logique du programme sera erroné jusqu’à ce que vous le fassiez”. Ce n’est pas le contrat que je m’attends à devoir appliquer lorsque je vois un produit jetable. Je m’attends à devoir faire un effort de bonne foi pour nettoyer une ressource quand bon me semble.

Si vous avez un object qui implémente IDisposable vous devez toujours appeler explicitement .Dispose() sur cet object. S’il .Dispose() pas IDisposable vous n’appelez évidemment pas .Dispose() car vous ne pouvez pas.

Si vous écrivez vos propres objects, la règle permettant d’implémenter ou non IDisposable est la suivante: Si votre object contient des références à des objects non gérés OU s’il contient des références à des objects qui implémentent IDisposable il doit implémenter IDisposable .

Le GC n’appelle jamais .Dispose() pour vous. Vous devez toujours le faire – directement ou par le biais d’un finaliseur.

Le GC peut (très probablement, mais pas toujours) appeler un finaliseur. Vous pouvez donc écrire un finaliseur pour appeler dispose, mais veillez à mettre en œuvre correctement le motif à usage unique et assurez-vous de bien comprendre que le finaliseur risque de ne pas être exécuté. si votre méthode dispose fait quelque chose d’extrêmement important, il peut être préférable d’appeler directement .Dispose() avant de perdre la référence à l’object.

Le garbage collector (GC) garantit que les ressources de mémoire gérées qui ne sont plus utilisées sont libérées avant que la limite de mémoire ne soit atteinte .

Décomposons cela:

managed : Lâchement, cela signifie des ressources entièrement dans .NET / CLR. La mémoire allouée par les bibliothèques non .NET C ++, par exemple, n’est pas libérée par le GC.

mémoire : le CPG ne garantit que l’utilisation de la mémoire. De nombreux autres types de ressources existent, tels que les descripteurs de fichiers. Le GC n’a pas de logique pour s’assurer que les descripteurs de fichier sont communiqués rapidement.

n’est plus utilisé : cela signifie que toutes les variables avec une référence à cette mémoire ont terminé leur vie. Comme Eric Lippert l’a expliqué, durée de vie! = Scope.

avant que la limite de mémoire ne soit atteinte : le CPG surveille la “pression de la mémoire” et veille à libérer de la mémoire en cas de besoin. Il utilise un ensemble d’algorithmes pour décider du moment le plus efficace, mais il est important de noter que le GC décide quand libérer des ressources toutes seules (de manière non déterministe pour votre programme).


Cela nous laisse plusieurs scénarios lorsque le recours au GC n’est pas approprié:

  • L’object fait référence à des ressources non gérées (y compris à un object géré faisant référence à une ressource non gérée).
  • L’object fait référence à une ressource autre que la mémoire qui doit être libérée.
  • L’object fait référence à une ressource qui doit être libérée à un point spécifique du code (de manière déterministe).

Dans tous les cas, l’object doit implémenter IDisposable pour gérer le nettoyage des ressources.

Tout object instancié qui implémente IDisposable doit être nettoyé en appelant Dispose ou en utilisant le bloc using (qui se charge d’appeler Dispose pour vous).

Le modèle Dispose peut être utilisé pour effacer les ressources gérées et non gérées. Si vous avez des ressources non gérées dans votre classe, selon l’ implémentation IDisposable appropriée, vous devez avoir les méthodes Dispose et Finalize.

Comment savoir ce que GC sait ou ne sait pas?

GC ne connaît / s’intéresse qu’aux objects gérés. Le GC est supposé effacer les objects qui n’ont pas de références solides. Il ne sait pas à propos de vos logiques. Pour un exemple simple et évident.

Supposons que vous avez une instance MainView qui dure longtemps et que vous créez un autre LittleView qui s’abonne à un événement dans l’instance MainView.

Ensuite, vous fermez le LittleView et il disparaît. Vous savez que vous n’avez plus besoin de cette instance de LittleView. Mais GC ne sait pas si vous avez toujours besoin de LittleView ou non, car il existe un abonnement d’événement actif à MainWindow.

Donc, GC ne prendra pas la peine d’effacer l’instance de LittleView de la mémoire. Donc, ce que vous devriez faire est de désabonner l’événement lorsque vous fermez la vue. Ensuite, GC sait qu’il n’ya pas de forte référence à la LittleView et qu’elle est accessible.

Le poste complique également les choses en disant que les ressources gérées peuvent inclure des ressources non gérées. Sensationnel. Cela devient plus profond que ce que j’avais initialement imaginé. Je cherche toujours à savoir facilement comment savoir ce qui doit être éliminé. S’agit-il d’une liste compliquée de conditions et de contexte?

C’est exact, les objects gérés peuvent également avoir des ressources non gérées. Tous ces objects gérés ont leur méthode de finalisation pour effacer les ressources gérées.

Je me demande pourquoi vous avez besoin de la méthode de finalisation en plus de l’élimination?

Les ressources non gérées peuvent créer les memory leaks les plus dangereuses car de telles fuites peuvent conserver la mémoire jusqu’au redémarrage du PC. Donc, ils sont très mauvais.

Supposons qu’il existe une instance gérée InsA avec certains non gérés. InsA a implémenté la méthode Dispose de manière à supprimer les ressources non gérées. Mais que se passera-t-il si vous n’oubliez pas d’appeler la méthode Dispose? Il ne sera jamais effacer cette mémoire non gérée. C’est pourquoi la finalisation est entrée dans la fonctionnalité. Donc, si vous oubliez / n’appelez pas le Dispose, la finalisation vous garantira d’exécuter le Dispose de manière à libérer les ressources non gérées.