Qu'advient-il si je ne suis pas d'appel dispose sur le stylo d'objet?

Ce qui se passe si je ne l'appelez pas Dispose sur le pen objet dans cet extrait de code?

private void panel_Paint(object sender, PaintEventArgs e)
{
    var pen = Pen(Color.White, 1);
    //Do some drawing
}

Rien. C'est pourquoi vous devriez l'appeler.
Il me semble que la documentation MSDN sur ce que la méthode n'est assez clair. msdn.microsoft.com/en-us/library/...
Eh bien, je suppose que je pourrais avoir formulé la question de ce qui ne se produit pas si je ne l'appelez pas Dispose, mais je crois que vous comprenez ce que je veux dire?
Une meilleure question est, pourquoi ne voulez-vous pas de l'appeler Dispose()? Si j'avais écrit cela, je le mettrait dans une instruction d'utilisation.
Je sais que je suis censé appeler dispose, j'essaie de comprendre pourquoi. Si c'est si important que je l'appelle, pourquoi n'est-il pas fait automatiquement?
.net ne fait pas échapper à l'analyse. Ainsi, il ne sait pas si la référence survit après pen est hors de portée. Ainsi, vous devez attendre jusqu'à ce que le GC décide de recueillir le Pen qui pourrait être beaucoup plus tard.
Et pour les objets qui font partie d'un objet graphique(ce n'est pas le cas pour Pen) l'objet peut être maintenu en vie par quelques références qui sont supprime uniquement si vous disposez de l'objet.
pourquoi n'est-il pas fait automatiquement? "Quand serait-il "l'appeler automatiquement" ??! Comment le cadre de déterminer le moment de l'appeler.. c'est à vous, le programmeur... et c'est pourquoi la langue concepteurs ont ajouté la using mot-clé, pour vous permettre de spécifier quand à appeler sans avoir à écrire explicitement un appel à elle...
Brinck: je sais que ce n'est pas la réponse à votre question. C'est pourquoi il n'était pas une réponse, mais un jeu de mots dans un commentaire. Même si je pense que le terme correct est "truisme" plutôt que de "sarcasme". Ou, peut-être, "wiseassery" - comme dans ce commentaire 😉
Si vous êtes trop paresseux pour type myobj.Dispose(), vous devez emballer votre code avec un [using énoncé](msdn.microsoft.com/en-us/library/yh598w02(v=VS.80).aspx.
Ce n'est pas juste de la paresse depuis que vous aviez besoin d'utiliser try...finally d'exception de sécurité et le code est plus difficile à lire qu'à l'aide de using.
Aller en prison. Aller directement à la prison. Ne passez pas aller, ne recueillent pas 200 dollars.
Le problème est que parfois vous ne pouvez pas utiliser "utiliser", par exemple lorsque votre classe doit contenir les champs de non géré type.

InformationsquelleAutor Andreas Brinck | 2010-11-24

c#dispose winforms

24

La Pen seront recueillies par le GC à un moment indéterminé dans l'avenir, si oui ou non vous appeler Dispose.

Cependant, toutes les ressources non managées détenus par la plume (par exemple, un RIB+ poignée) ne seront pas nettoyés par le GC. Le GC seulement nettoie les ressources gérées. L'appel de Pen.Dispose vous permet de vous assurer que ces ressources non gérées sont nettoyés en temps opportun et que vous n'êtes pas des fuites de ressources.

Maintenant, si le Pen a un finaliseur et que finaliseur nettoie les ressources non managées, puis les ressources non managées sera nettoyée lors de la Pen est des ordures collectées. Mais le fait est que:
1. Vous devriez appeler Dispose explicitement afin que vous libérer de vos ressources non managées, et
2. Vous ne devriez pas avoir à vous soucier de la mise en œuvre détail de si il y a un finaliseur et il nettoie les ressources non managées.
Pen implémente IDisposable. IDisposable est de disposer des ressources non managées. C'est le modèle dans les .NET.

Pour les commentaires précédents sur ce sujet, voir ce réponse.
- Cette réponse est incomplète et un peu trompeur. J'ai décrit pourquoi dans mon post ci-dessous.
- -1 pour l'affirmation que le GC ne pas nettoyer les ressources non managées. Si la IDisposable mise en œuvre fait cela correctement, il fonctionne très bien à partir de la finalisation fil, mais juste assez tard.
- Le GC ne libère pas la mémoire non managée ou de ressources - indépendamment de la manière dont Dispose() est mise en œuvre. Ce peut faire est de vous permettre d'appeler le Maréchal.ReleaseComObject() et de mettre en œuvre un Finaliseur qui sera appelée si GC.SuppressFinalize() n'est pas appelée. Tout simplement parce que le nettoyage de la mémoire non gérée se produit au cours de Finalisation ou d'en Disposer de la mise en œuvre, ne signifie PAS que la GC est la pour faire de la libération. Le GC n'est pas responsable du nettoyage de ressources non managées - si le programmeur ne fait jamais de la sorte, alors que la mémoire sera coulé.
- La MSDN Docs (msdn.microsoft.com/en-us/library/...) sur la Plume en désaccord avec vous. "Toujours faire appel à Éliminer avant de vous libérer de votre dernière référence à la Plume. Sinon, les ressources qu'il utilise ne sera pas libéré jusqu'à ce que le garbage collector appelle le Pen objet de la méthode Finalize." Sauf si mal écrit, je suppose que "les ressources" sont toutes les ressources, aussi non managés. De sorte que la GC, en effet, que la libération des ressources non managées dans ce cas.
- le GC ne sait rien directement sur les ressources non managées: pas comment leur attribuer, et non pas comment les libérer. Ce que la langue n'est de vous fournir un moyen de le gérer vous-même via Disposer avec un Finaliseur. Techniquement parlant, le Pen de la classe n'est pas une ressource non managée; c'est plutôt un wrapper géré sur une ressource non managée. Le code sous-jacent dans le Stylo classe implémente un Finaliseur. Le Finaliseur de cette classe ne de la tâche nécessaire de nettoyage pour lorsque vous traitez avec des objets gérés, les ressources sont généralement pas de "fuite" (à de très rares exceptions).
InformationsquelleAutor jason
27

Quelques corrections doivent être faites ici:

Concernant la réponse de Phil Devaney:

"...Appeler dispose vous permet de faire le nettoyage déterministe et est fortement recommandé."

En fait, l'appelant Dispose() n'est pas de façon déterministe de provoquer un GC collection .NET - c'est à dire qu'il ne déclenche PAS un GC immédiatement simplement parce que vous avez appelé Dispose(). Seulement indirectement des signaux à la GC que l'objet peut être nettoyé au cours de la prochaine GC (pour la Génération dont l'objet réside dans). En d'autres termes, si l'objet réside dans Gn 1, alors il ne serait pas éliminés jusqu'à ce qu'un Gn 1 collecte. L'un des seuls moyens (mais pas le seul) que vous pouvez par programmation et la conception déterministe de la cause de la GC pour effectuer une collection est en appelant GC.Collect(). Cependant, cela n'est pas recommandé puisque le GC "tunes" lui-même au cours de l'exécution par la collecte de statistiques sur vos allocations de mémoire lors de l'exécution de votre application. L'appel de GC.Collect() vidages de ces mesures et les causes de la GC pour commencer sa "mise au point" une fois de plus.

Concernant la réponse:

IDisposable est pour l'élimination non géré ressources. C'est le modèle dans les .NET.

C'est incomplète. Comme le gouvernement du canada est non-déterministe, le Modèle dispose, (Comment mettre correctement en œuvre le modèle dispose), est disponible de sorte que vous pouvez libérer les ressources que vous utilisez - gérés ou non. Il a rien à faire avec ce genre de ressources qui vous sont releasing. La nécessité de la mise en œuvre d'un outil de finalisation n'ont à voir avec ce genre de ressources que vous utilisez - savoir mettre en œuvre un si vous avez de la non-finalisable (c'est à dire natif) des ressources. Peut-être que vous confondez les deux. BTW, vous devriez éviter de mettre en œuvre un outil de finalisation par l'aide de la SafeHandle classe à la place qui enveloppe de ressources autochtones qui sont recueillis par P/Invoke ou COM Interop. Si vous finissez par la mise en œuvre d'un outil de finalisation, vous devriez toujours mettre en œuvre le Modèle dispose.

Une critique remarque que je n'ai pas vu personne mentionner encore, c'est que si jetables objet est créé et il a un Finaliseur (et vous ne jamais vraiment savoir si elles le font, et vous avez certainement ne devriez pas faire d'hypothèses à ce sujet), elle sera directement envoyé à la File d'attente de Finalisation et de vivre pendant au moins 1 supplémentaire GC collection.

Si GC.SuppressFinalize() n'est pas en fin de compte appelée, le finaliseur pour l'objet sera appelé sur le prochain GC. Notez qu'une bonne mise en œuvre du modèle dispose devriez appeler GC.SuppressFinalize(). Ainsi, si vous appelez dispose() sur l'objet, et il a mis en œuvre le modèle correctement, vous permettra d'éviter l'exécution de l'outil de finalisation. Si vous n'appelez pas Dispose() sur un objet qui a un finaliseur, l'objet aura sa Finaliseur exécuté par le GC sur la collection suivante. Pourquoi est-ce mauvais? Le Finaliseur fil dans le CLR jusqu'à et y compris .NET 4.6 est mono-thread. Imaginez ce qui se passe si vous augmentez le fardeau sur ce fil - votre les performances de l'application va vous savez où.

Appeler dispose sur un objet contient les éléments suivants:
1. réduire la pression sur le GC pour le processus;
2. réduire l'application de la pression de la mémoire;
3. de réduire le risque de OutOfMemoryException (OOM) si la liturgie des heures (des Objets Volumineux) est fragmenté et l'objet est sur la liturgie des heures;
4. Conserver l'objet de la Finalisable et f-accessible Files d'attente si il a un Finaliseur;
5. Assurez-vous que vos ressources (gérés et non gérés) sont nettoyées.
Modifier:
Je viens de remarquer que le "tout en sachant et est toujours correct" de la documentation MSDN sur IDisposable (extrême sarcasme ici) en fait ne dit

La principale utilisation de cette interface est
pour libérer des ressources non managées

Que tout le monde devrait savoir, MSDN est loin d'être correct, ne mentionne jamais ou montre des "meilleures pratiques", parfois fournit des exemples qui ne compile pas, etc. Il est regrettable que cela est décrit dans ces mots. Cependant, je sais ce qu'ils essayaient de le dire: dans un monde parfait, le GC nettoyage de tous les géré ressources pour vous (comment idéaliste); il ne sera pas, cependant nettoyage non géré ressources. C'est absolument vrai. Cela étant dit, la vie n'est pas parfaite et il n'est ni n'importe quelle application. Le GC ne de nettoyage de ressources qui n'ont pas enracinée références. C'est principalement là où se trouve le problème.

Parmi environ 15-20 façons différentes .NET peut "fuite" (ou pas gratuit) de la mémoire, celle qui seraient le plus susceptibles de vous mordre si vous ne faites pas appel Dispose() est le fait de se désinscrire/décrocher/unwire/détacher des gestionnaires d'événement/délégués. Si vous créez un objet qui a des délégués filaire et vous n'appelez pas Dispose() (et ne pas détacher les délégués à vous-même), le GC va toujours voir l'objet comme ayant enracinée références à - dire les délégués. Ainsi, le GC ne sera jamais le recueillir.

@joren commentaire/question ci-dessous (ma réponse est trop long pour un commentaire):

J'ai un blog sur le modèle dispose je recommande d'utiliser - (Comment mettre correctement en œuvre le modèle dispose). Il ya des moments où vous devez null références et il ne fait jamais de mal de le faire. En fait, cela ne le faire quelque chose avant le GC s'exécute - il supprime la référence enracinée de cet objet. Le GC analyses ultérieures sa collection de enraciné références et recueille ceux qui n'ont pas de référence enracinée. Pense de cet exemple, il est bon de le faire: vous avez une instance de type "ClassA" - appelons-le "X". X contient un objet de type "ClassB" - appelons cela "Y". Y implémente IDisposable, donc, X devrait faire de même à jeter Y. supposons que X est dans la Génération 2 ou la liturgie des heures et Y est dans la Génération 0 ou 1. Lorsque dispose() est appelée sur X et que la mise en œuvre des valeurs null référence de Y, la référence enracinée de Y est immédiatement supprimé. Si un GC qui se passe pour la génération 0 ou Gn 1, la mémoire/des ressources pour Y est nettoyé mais la mémoire/des ressources pour X n'est pas depuis X vit dans Gen 2 ou la liturgie des heures.
- À l'égard d'une contradiction apparente, Jason a déclaré "IDisposable est de disposer des ressources non managées". Son seul but est de façon déterministe de nettoyage de ressources - qu'elles soient ou non gérés. Mettre en œuvre le modèle dispose correctement, vous offre, pour le nettoyage de vos ressources. Je ne dis pas que les ressources non managées ne sont pas nettoyés, plutôt que le but de IDisposable est orthogonal à la nature des ressources qui vous sont les jeter. On pourrait conjecturer à partir de sa déclaration que vous n'avez pas besoin de mettre en œuvre IDisposable sauf si vous utilisez une ressource native - ce qui est absolument faux.
- merci pour la clarification. Je suis d'accord avec vous que l'on pourrait être conduit à cette fausse conclusion basée sur une lecture superficielle. OMI, le manque d'exhaustivité dans Jason réponse est acceptable étant donné que c'est l'exactitude compte tenu de l'OP question spécifique. Cependant, je pense que votre évaluation est utile.
- regarde mon commentaire ci-dessus, j'ai remarqué que j'ai une faute de frappe...j'ai accidentellement dit "de façon déterministe de nettoyage de ressources". Il doit avoir été "non déterministe". Si je pouvais modifier le commentaire ci-dessus, je le ferais 🙂
- -1 pour "en Fait, l'appelant Dispose() n'est pas déterministe, dans .NET". Mal - appelant Dispose() est déterminé par le fait que vous l'avez appelé. En fait, la plupart des implémentations de Dispose() explicitement drapeau de l'objet comme ne nécessitant pas de mise au point, parce que tout ce qui est nécessaire a déjà été fait.
- Salut Dominic, il devrait être évident que ce que je voulais dire, c'est que juste parce que vous appelez dispose() de façon déterministe (c'est à dire de manière synchrone), cela ne signifie pas que le GC exécuter immédiatement une collection (c'est à dire de façon déterministe). L'un des seuls moyens, mais pas le seul, de la conception déterministe de la cause de la GC pour effectuer une collecte est l'appel de GC.Collect() - qui n'est pas recommandé. Depuis que ma réponse n'était pas claire, je vais le modifier pour le rendre plus clair. Désolé pour la confusion.
- Ce type de mise en œuvre de Disposer proposez-vous pour nettoyer les ressources gérées? Vous n'êtes pas en se référant à micropression hors géré références, je suppose, puisque cela ne fait rien, jusqu'à ce que le GC s'exécute, et s'il fonctionne, ne fait rien qui invalide les références à l'objet que vous êtes l'élimination n'est pas déjà fait. Mais je ne peux pas penser à quelque chose d'autre, vous pourriez être en train de parler, expliquer.
- J'ai édité ma réponse ci-dessus pour répondre à votre question (ma réponse est trop long pour être un commentaire). J'espère que cela aide à clarifier les choses.
- Je vois ce que tu veux dire. Mais si je ne this.Foo.Dispose(); this.Foo = null; alors il n'a pas d'importance si Foo.Dispose les valeurs null de ses références ou pas, car il n'est plus un chemin de la GC, les racines de l'objet, de toute façon. Si vous êtes seulement à l'aide de Disposer de références nulles, alors vous pourriez aussi bien ne pas utiliser de Disposer à tous et tout simplement se débarrasser de la référence à l'objet directement. Donc MSDN que l'utilisation principale est de libérer des ressources non managées est vrai, puisque tout le reste peut être aussi bien réalisé, sans elle, aussi longtemps que vous ne vous accrochez pas à des références à des objets que vous n'utilisez pas.
- Vous avez raison - micropression la référence après l'appel de disposer en fera de même. Cependant, pas d'appel dispose() sur un objet qui est Jetable place dans la file d'attente de Finalisation de la GC. Cela augmente la pression sur la mémoire et diminue GC performance. Une fois qu'un objet est placé dans la File d'attente de Finalisation, il survivre au moins 2 GC collections - une fois pour la File d'attente de Finalisation, une fois pour le f-accessible File d'attente. En outre, la finalisation n'est effectuée que sur un FULL GC collection qui, même dans un bon app, peut se produire environ 1 sur 100 collections.
- BTW, si vous êtes seulement en utilisant Dispose() null références, vous êtes vraiment en train de faire quelque chose de mal!
- Pas nécessairement. Si à court terme l'objet de demandes de notification à partir d'une longue durée de vie de l'objet, il est nécessaire de s'assurer que lors de la courte durée de vie de l'objet n'est plus nécessaire de la longue durée de vie, l'objet ne sera pas le garder en vie. Si de nombreux objets éphémères qui se chevauchent durée de vie, bon amorti temps d'abonnement et de désabonnement peut, par le fait, pour chaque abonnement souscrit un "lien" de l'objet avec une référence à l'objet éphémère, la manipulation de désabonnement par micropression le lien de référence, et, périodiquement, le balayage de la liste de souscription pour les liens morts...
- ...à un taux déterminé par le nombre de liens direct.
- Je pense qu'il est sûr de supposer que si IDisposable est mis en œuvre, il a des ressources qui ont besoin de libérer de manière déterministe. Si il y a ou non des ressources non managées est un détail d'implémentation.
- Je suis en désaccord. Vous êtes essentiellement à dire que vous avez seulement besoin de mettre en œuvre Disposer si vous avez des ressources qui doivent être libérés de façon déterministe (non géré). Exactement comment ces ressources sont libérées doivent être en interne MSCOREE (ExecutionEngine) détail (c'est à dire déterministe ou non) et concernent pas le développeur (même si c'est toujours bon de savoir comment votre cadre de travaux). La même chose s'applique à la façon dont la mémoire est allouée. Il y a beaucoup d'exemples dans l' .NET Framework/.NETCore lorsque vous voulez mettre en œuvre en Disposer, même si vous n'avez pas les ressources non managées.
- Pas exactement, j'ai été en accord était qu'un détail d'implémentation. Le fait que la IDisposable modèle est si mal comprise en est une nouvelle preuve. Essentiellement, il est bon de ne pas appeler de Disposer en code managé. Pour certains scénarios complètement inutile MemoryStream être un exemple.
- Je pense que vous avez complètement raté le point de ma réponse. Il n'est PAS ok pour éviter l'appel de Disposer en code managé. J'ai expliqué en détail exactement pourquoi tit nécessaire. Ligne de fond est la suivante: si une classe implémente IDisposable, vous devriez être en l'appelant. Pour dire, dans un cas, vous n'avez pas besoin de Disposer d'appel en raison de la façon dont une certaine classe est mis en œuvre est un mauvais design - vous êtes en s'appuyant sur la mise en œuvre interne de détails qui doivent être traités comme des boîtes noires - par exemple MemoryStream, et tous les autres .NET Framework (ou d'un autre cadre externe) de la classe. Interne implémentations de changement.
- l'une des raisons de la IDisposable modèle est si mal compris est que les gens (comme vous) voulez de se préoccuper de savoir si la ressource sous-jacente est en utilisant gérés ou non des ressources - comme si c'est le facteur décisif - il pas être le facteur décisif. Si vous vous en tenez à l'idée de "si elle met en œuvre IDisposable, alors que je devrais l'appeler Dispose()", vous serez d'accord à 100% du temps. Si l'on suit ces conseils, il y en avait peu, le cas échéant, de la confusion sur le motif.
- Vous avez raison, bien sûr. 90% du temps
- pour le record, je ne voulais pas de manque de respect, quand j'ai dit "des gens comme toi-même". J'étais tout simplement descriptive.
InformationsquelleAutor Dave Black
13

Le sous-jacent GDI+ stylet poignée ne sera pas libéré jusqu'à ce qu'une période indéterminée, dans l'avenir, c'est à dire lorsque le Stylet objet est nettoyée et le finaliseur de l'objet est appelé. Cela peut ne pas être jusqu'à la fin du processus, ou il peut être plus tôt, mais le point est non-déterministe. Appeler dispose vous permet de faire le nettoyage déterministe et est fortement recommandé.
- Cette réponse est un peu incorrect. J'ai décrit pourquoi dans mon post ci-dessous.
InformationsquelleAutor Phil Devaney
2

Le montant total de .Net de la mémoire dans l'utilisation de la .Net part + toutes les données en cours d'utilisation. OS des objets, ouvrir des fichiers, base de données et toutes les connexions réseau de prendre certaines ressources qui ne sont pas purement .Net des objets.

Graphique utilise des Stylos et d'autres objets qui sont en fait des OS, des objets qui sont "très" cher de garder autour. (Vous pouvez échanger votre Stylet pour une 1000x1000 fichier bitmap). Ces OS que les objets sont supprimés de la mémoire du système d'exploitation une fois que vous avez d'appeler un fonction de nettoyage. Le Stylo et le Bitmap de Disposer des fonctions de le faire pour vous immédiatement lorsque vous les appelez.

Si vous n'appelez pas la Jeter à la poubelle collecteur en viendra à nettoyer, " quelque part dans le futur*'.
(Il se fait appeler le destructeur/finaliser le code que probablement appelle dispose())

*sur une machine avec un nombre infini de mémoire (ou de plus de 1 GO), quelque part dans l'avenir peut-être très loin dans le futur. Sur une machine à ne rien faire, il peut être facilement plus de 30 minutes pour nettoyer cette énorme bitmap ou très petite plume.

InformationsquelleAutor CodingBarfield
2

Si vous voulez vraiment savoir comment c'est quand vous n'appelez pas Jeter sur des objets graphiques, vous pouvez utiliser le CLR Profiler, disponible gratuitement pour le téléchargement ici. Dans le dossier d'installation (par défaut C:\CLRProfiler ) est CLRProfiler.doc qui a un bon exemple de ce qui se passe lorsque vous ne l'appelez pas Jeter sur une Brosse objet. Il est très éclairant. Vous pouvez aussi lire sur l'utilisation de IDisposable ici et ici.

InformationsquelleAutor Bill W
1

Va conserver les ressources jusqu'à ce que le garbage collector il nettoie
- pas si ils sont GDI+ non géré poignées....
- Wong! La poignée va rester jusqu'à ce que le processus est terminé.
- les stylos finaliseur de nettoyer les ressources, s'il s' msdn.microsoft.com/en-us/library/... bien sûr, il n'y a pas de garantie, il sera exécuté
- Tous les objets qui s'étendent Component mettre en œuvre un outil de finalisation d'appel Dispose. Le finalizer est non-déterministe, ce qui signifie que vous ne pouvez pas prédire quand elle fonctionne, mais il sera toujours courir par la suite. Si un autre finaliseur bloque indéfiniment, ou que le processus est tué alors bien sûr, il ne sera pas exécuté.
- Et de normal finaliseur ne sera pas appelé lorsque le domaine d'application est déchargée après une exception non interceptée. Vous avez besoin d'une critique finaliseur pour que. Mais je suppose qu'un Stylo utilise un safehandle et donc critique de finalisation, mais je n'ai pas vérifier.
InformationsquelleAutor m.edmondson
1

Dépend si elle met en œuvre finaliseur et il appelle les Disposer sur sa méthode finalize. Si oui, la poignée sera publié au GC.

si pas, poignée rester autour jusqu'à ce que le processus est terminé.
- "Toujours faire appel à Éliminer avant de vous libérer de votre dernière référence à la Plume. Sinon, les ressources qu'il utilise ne sera pas libéré jusqu'à ce que le garbage collector appelle le Pen objet de la méthode Finalize." msdn.microsoft.com/en-us/library/...
InformationsquelleAutor Aliostad
0

Graphique avec des trucs il peut être très mauvais.

Ouvrez le Gestionnaire des Tâches de Windows. Cliquez sur "sélectionner les colonnes" et choisissez colonne appelée "Objets GDI".

Si vous ne mettez pas au rebut de certains objets graphiques, ce nombre va continuer d'augmenter et de sensibilisation.

Dans les anciennes versions de Windows, cela peut faire planter l'ensemble de l'application (limite était de 10000 comme je me souviens bien), ce n'est pas sûr Vista/7, mais c'est toujours une mauvaise chose.
- Ne GDI+ utilisation GDI objets? Autant que je sache, WinForms utilise GDI+ et pas GDI pour la plupart de ses fonctionnalités.
- rapide test a confirmé que le fait d'avoir Crayon des objets dans l'événement OnPaint augmenter la valeur des Objets GDI, donc probablement il se compose de deux GDI et GDI+ objets.
- Supposons qu'un programme devra utiliser des stylos de différentes couleurs. Quels seraient les avantages et les inconvénients entre (1) le fait d'avoir plusieurs commandes de chacun de produire et de maintenir un ensemble de stylos, Disposeing d'eux quand il était lui-même Disposed; (2) la création de stylos toujours à la demande et de ne jamais le cache d'eux; (3) ayant un mondial Dictionary<Color, Pen> qui dure aussi longtemps que la demande, ou (4) avoir un mondial Dictionary<Color, WeakReference> qui tiendrait une WeakReference à chaque stylo?
- récemment j'ai été confronté à un problème similaire dans un de mes projets, il a terminé avec #3 - dictionnaire créé une fois et jetés lorsque l'application est détruit. Il fonctionne bien et rapidement, mais ne peut pas dire que c'est l'agent ou de la meilleure façon.
- Il semble analogue à la formation de chaînes de caractères. Le WeakReference approche semble avoir un certain mérite également dans les cas où un contrôle de la tenue d'un objet graphique dans un domaine, mais de nombreux contrôles peut vouloir organiser le même (donc le nombre de contrôles en tenant un objet particulier peut varier de quelques centaines à zéro).
InformationsquelleAutor Shadow Wizard
-1

le garbage collector permettra de recueillir de toute façon, MAIS c'est important QUAND:
si vous ne vous appelez dispose d'un objet que vous ne l'utiliser vivent plus longtemps en mémoire et sera promu à la hausse des générations, ce qui signifie que la collecte, il a un coût plus élevé.
- vous semblez être misunderstaning pourquoi Jeter il y a...pas mon downvote BTW...
InformationsquelleAutor Ali Tarhini
-3

dans le dos de mon esprit la première idée est venue à la surface, c'est que cet objet sera détruit dès la fin de l'exécution de la méthode!, je ne sais pas où j'ai eu cette info!, est-il juste?
- Il ne se passe pas comme ça en C# (ou .NET en général d'ailleurs)
InformationsquelleAutor Rami Shareef

Vous devez vous connecter pour publier un commentaire.