9
votes

Il suffit d'ouvrir et de fermer la boîte de dialogue Winform augmentera l'utilisation de la mémoire

J'essaie de réduire l'utilisation de la mémoire d'une application Winform.

Il existe une forme principale et un formulaire de réglage dans l'application. Lorsque vous appuyez sur le bouton "Réglage", le formulaire de paramétrage contemplera en tant que formulaire modal, le formulaire de paramétrage chargera des données app.config du fichier de configuration et les lisez à la mémoire en tant que hasble. Une fois le formulaire de réglage fermé, il appellera la méthode de disposition inhérente à partir de Windows.Forms.Form. La méthode de jet est aussi simple que de définir les hashtables et l'objet APP.Config vers NULL. P>

Signification de formulaire de configuration comme modalform: strong> p>

mySetting.Dispose();
testFtp.Dispose(); 


8 commentaires

Cela vous aiderait si vous avez posté au moins une partie de votre code, en particulier le code où vous affichez le formulaire de manière moderne et votre méthode de jettement complète du formulaire de réglage.


En outre, une simple journalisation ou débogage. Appel d'empreinte ou peu importe à l'intérieur de la méthode d'expiration confirmera s'il est en réalité appelé ou non.


Réglage de la référence à NULL ne libère pas la mémoire.


Mise à jour: appelant Dispose () ne libère pas la mémoire, non plus. Vous devez attendre une collection de déchets (qui se produira lorsque le système pense qu'il est préférable, ou vous pouvez le forcer avec gc.collect () ).


@Travis: GC.Collect est une sorte de piratage, une sorte de sucette, pas une solution. Ce n'est pas recommandé.


@Nayan: Je sais, mais c'est un bon moyen de dire rapidement si les ressources seront nettoyées par le collecteur des ordures. Je suppose que je devrais toujours inclure un "mais ne fais pas gc.collect () dans la production" Clause :-D


D'accord, je vais presque dire la même chose que Travis. J'ai vu chaque mention de GC.Collect aura le même type de réponse que je suppose que c'est une bonne chose pour Newbie comme moi. Donc, sans dire, je prends l'avis de GC.Collect () de Tarvis teste une théorie. Encore une fois, une mémoire des centaines de K a peut-être été significative dans la réelle utilisation de mon application la plupart du temps. Je dois juste le comprendre.


Travis Gockel: Qu'est-ce qui vous fait penser à appeler Dispose ne libère pas de mémoire? Vraisemblablement appeler form.Dispose () détruit le HWND associé au formulaire, qui libérerait une certaine mémoire (mais pas beaucoup).


3 Réponses :


1
votes

La mémoire peut ne pas être libérée à cause d'un autre morceau de code aussi. Puisque vous n'avez pas fourni de plus de détails, je suppose maintenant que tout le reste est optimal.

Les objets que vous travaillez sont collectés par le collecteur des ordures (comme vous le savez). Mais ils ne peuvent pas être libérés de la mémoire quand vous le voulez. Les objets .NET sont mieux laissés à la poubelle.

Selon la raison pour laquelle la mémoire ne peut pas être publiée, Vous avez les réponses ici.

Régler la référence d'objet à NULL ne fait pas beaucoup de différence. D'autre part, j'ai personnellement enregistré des moments, des objets revenus vivants (et poussés à vieilles générations) parce que vous les utilisez tout en fixant NULL vers la même manière. C'est une autre forme d'interférence avec GC, mais votre choix.

Vous n'avez peut-être pas besoin d'implémenter Idisposable , mais si vous travaillez avec des flux, des poignées du système d'exploitation, des ressources non gérées, vous devriez alors.

EDIT:

L'utilisation de la mémoire peut être élevée, mais c'est la responsabilité de GC de libérer aussi longtemps que vous ne gardez pas de références vivantes. Donc, si vous avez pris toutes les précautions, cela peut toujours sembler que votre demande consommait beaucoup de mémoire. Qui est acceptable comme libérant les objets non référencés est la responsabilité du collecteur à la poubelle.


2 commentaires

Selon cet article, j'ai trouvé que cela est très utile pour le débutant comme moi, DOTNETFUNDA.com/Articles/... Augmentation constamment dans l'utilisation de la mémoire de l'octet privé indique une fuite des ressources non gérées, dans ce cas, je dois m'assurer qu'ils sont correctement libérés, ce qui signifie que j'ai besoin de manière imissible jusqu'au bout, je pense?


C'est un excellent article que j'ai manqué. Merci pour ça! OK, si vous "savez" que c'est une fuite de mémoire non gérée, puis recherchez des emplacements où la mémoire non gérée est allouée. Vous pouvez implémenter l'interface Idisposable et publier les membres non gérés de l'objet. Mais assurez-vous également que les codes dont la portée est limitée à une fonction, libérant également la mémoire. Ils ne peuvent pas être libérés pour disposer de la méthode. Par exemple: fermer un flux dans une fonction - cela ne peut être manipulé que dans cette fonction! Tous mes vœux!



0
votes

Pourquoi pensez-vous que c'est une fuite? GC n'est pas obligé de libérer la mémoire instantanément, dans certaines circonstances, il peut ne jamais effectuer la collection et cela irait bien.

Si vous avez vraiment besoin de ces kilo-octets libérés immédiatement, vous risquez de forcer GC à effectuer le nettoyage juste après la cessation, mais c'est une opération coûteuse en général et peut affecter les performances globales.


0 commentaires

2
votes

Comme vous l'avez suggéré près de la fin de votre question, je vous recommanderais de mettre en œuvre Idisposable sur mysetting et testftpp . Vous devriez voir un meilleur nettoyage des ressources une fois que vous avez implémenté les éléments suivants: xxx

petit édition: Basé sur la réponse de Nayan et la réponse qu'il relie: Je recommande vivement la mise en œuvre de Idisposable . Utilisation de formulaires et dérivé à partir des formulaires FORMES CLASS SRAMEAMS ", vérifiez la nécessité d'implémenter Idisposable ". Cela ne signifie pas que votre code devrait la mettre en œuvre, juste que vous devriez vraiment vérifier pour vous assurer de ne pas en avoir besoin. Les formulaires ont généralement beaucoup d'événements publiés et souscrits à. Les formulaires sont également notoires pour devenir un godet de capture - tout ressource, imo.


1 commentaires

Merci, je pense que la gestion de la mémoire dans .net n'est vraiment pas si simple exclure quelques-unes évidemment des choses. J'ai à peu près toutes les choses nécessaires (Idisposables jusqu'à ce qu'elle ait un sens (ressources non gérées Invloved) et de deux profileurs croisés). Semble que l'utilisation de la mémoire est beaucoup plus stable maintenant. Mais toujours en utilisant plus au fil du temps. Je veux dire si je me soucie de la mémoire beaucoup, je devrais envisager de supprimer toutes les choses d'interface graphique et de penser à utiliser C ++ ou C: D