Explicitement la libération de la mémoire en c#

J'ai créer une application en c# qui utilise jusqu'à 150 mo de mémoire (en octets privés), principalement en raison d'un gros dictionnaire:

Dictionary<string, int> Txns = new Dictionary<string, int>();

Je me demandais comment faire pour libérer cette mémoire. J'ai essayé ceci:

Txns = null;
GC.Collect();

Mais il ne semble pas faire beaucoup de trou dans ma octets privés - ils abandonnent de dire 155mb à 145mb.
Toute indices?

Grâce

-edit-

Bon, je vais avoir plus de chance avec ce code (il reçoit les octets privés vers le bas à 50 mo), mais pourquoi?

Txns.Clear(); //<- makes all the difference
Txns = null;
GC.Collect();

-edit-

Bon pour tout le monde qui dit " ne pas utiliser GC.collect", juste assez (je ne vais pas le débat, autre que de dire que vous pouvez le voir mon C en arrière-plan à venir à travers, mais il n'a pas vraiment répondu à ma question:
Pourquoi ne le garbage collector seulement de libérer de la mémoire, si je la liste des transactions en premier? Ne devrait-il pas libérer de la mémoire, de toute façon, depuis le dictionnaire a été déréférencé?

  • GC.Collect() ne pas appliquer que la quantité de mémoire qui pourrait être recueillis sont recueillies lors de la collecte des déchets est un processus multi-étapes. Un processus que je pourrais ajouter que vous n'avez généralement pas besoin de savoir les détails à propos de...
  • Est-il nécessaire de mettre en Txns null, ça va faire une différence? ou tout simplement de Compensation le contenu est assez(pour libérer de la mémoire)?
InformationsquelleAutor Chris | 2009-05-05
  1. 17

    Octets privés reflètent le processus de " l'utilisation de la mémoire. Lorsque les objets sont recueillis à la mémoire associée à l'segment peut ou ne peut pas être libéré de l'OS. Le CLR qui gère la mémoire au niveau de l'OS et puisque l'allocation et la libération de la mémoire n'est pas gratuit, il n'y a aucune raison pour gratuit chaque morceau de la mémoire, comme les chances sont que l'application sera probablement demande plus de mémoire plus tard.

    • Tout cela semble raisonnable, mais c'est vraiment t libérer de la mémoire pour le système d'exploitation si je l'appelle Txns.Clear(). De Plus, j'ai vraiment envie d'être gentil avec les OS de la mémoire, puisque je ne suis pas le seul à utiliser ce serveur.
    • Je suppose que ce que je demande est, pourquoi ne txns.Clear() donner de la mémoire au système d'exploitation, lorsque deferencing la totalité du dictionnaire ne donne pas de retour?
    • Le point est que, dans une application managée vous avez fait un pas retiré de traiter directement avec les OS de la mémoire comme le CLR fait pour vous. Vous pourriez être en mesure de construire des scénarios où vous pouvez observer un effet direct comme vous le décrivez, mais qui n'est pas garanti que vous selon les détails de mise en œuvre de la CLR.
    InformationsquelleAutor Brian Rasmussen
  2. 11

    si u appel GC.Collect() elle commence à faire son travail , mais il revient tout de suite, il ne marche pas de bloc, de sorte que vous ne voyez pas de ses effets, si vous appelez GC.WaitForPendingFinalizers() après qu'elle bloquera votre application jusqu'à la GC.Collect() terminer son travail

    • Oups! Ne peux même pas commencer à penser à des niveaux de la méchanceté de partir un thread qui periodially (et assez souvent: il essaie deux fois par seconde!) appels GC.Recueillir et puis attend tous en attendant les finaliseurs. Êtes-vous juste totalement pas intéressés par la mise à l'échelle des applications? C'est juste essayer de cacher un symptôme de mauvais, mal! Pense que je vais avoir à -1 ici...
    • d'accord, mais pour être juste, il ne explicitement de répondre à la question. Si est une bonne idée ou pas est une autre question.
    • à contrecœur accepté. Dois-je -1 la question de la place alors...? Aussi semble inutilement difficiles et inutiles. Oh bien.
    • Je ne suis pas sûr que c'est tout à fait correct. Un garbage collection sera (peut?) réveiller le finaliseur fil, qui fonctionne ensuite les finaliseurs en tant que de besoin. Ainsi, en attente pour le finaliseur n'est pas vraiment d'attente pour la collecte des ordures à la fin (comme GC qui se passe sur un autre thread)
    • Salut, Merci pour cette réponse, mais il ne semble pas faire une différence, que j'ai essayé et les octets privés ne sont pas descendus: //Txns.Clear(); Txns = null; for (int x = 0; x < 20; x++) { GC.Collect(); GC.WaitForPendingFinalizers(); } Maintenant, gardez à l'esprit tout le monde c'est la preuve du concept de code! Sa ne va pas dans la production. Mais la seule façon que je peux le faire pour libérer de la mémoire, est l'appel du dictionnaire est Clair méthode, que je ne pas appeler, depuis que je suis en référence à l'ensemble du dictionnaire.
    • Peshlr -, qui a fait état de départ de threads et de l'exécution de la GC deux fois par seconde? C'est qu'une révision antérieure de la réponse ci-dessus?
    • Je ne suis pas expert sur la GC, mais j'ai vraiment couru dans un scénario où j'avais besoin de le faire (au moins, il fixe le problème que j'ai). Je l'ai utilisé pour libérer les objets Com. L'appel de Collecter des() et WaitForPendingFinalizers() sur la GC a résolu le problème. Dans toutes mes années de programmation, je n'ai jamais eu explicitement gc.Collect() jusqu'à présent.

    InformationsquelleAutor Sadegh
  3. 5

    La plupart vous avez probablement caché de référence pour le dictionnaire à un autre endroit. Ainsi, le dictionnaire n'est pas collectée, mais si vous Clear(), le contenu obtenir recueillies.

    Comme d'autres l'ont déjà noté, forçant le GC n'est pas recommandé. Cela pourrait conduire à la mémoire d'être poussé vers la plus "générations" qui ne sont pas souvent recueillies, et ainsi de gaspiller plus de mémoire que gagner dans le long terme.

    • Nope, pas de références cachées dans le dictionnaire.
    • Votre commentaire à propos de pousser des objets dans les générations subséquentes, le soin d'élaborer? Qui sonne comme une question d'être conscient de.
    • Accroche-toi, j'ai pensé que si vous appelez gc.recueillir sans arguments, c'est tout simplement recueille tous générations? Ne serait-ce pas à la règle ce problème avec les poussant des trucs dans les générations subséquentes? Merci.
    • GC.Collect() ne recueillir tous les gens. Il y a deux problèmes ici. 1) de l'appeler une fois: encore référencé la mémoire est poussé vers le haut, ce qui retarde la collection normale, et 2) de l'appeler régulièrement les déchets de plus de cpu car le gc doit traiter tous les gens à chaque fois. Alors ce que vous faites avec le GC.Collect(), vous perdez. Sauf, bien sûr, dans ces cas spéciaux où ces effets ne sont pas importantes pour vous.
    • L'exécution d'un profileur de mémoire, à ce stade, aurait prouvé plus cachés de référence existent.
    InformationsquelleAutor David Schmitt
  4. 4

    Pas sûr à partir de la mémoire si Dictionary a un Dispose() ou pas, mais il est lié à une Clear(). Appelez une de ces avant de régler les références à null.

    Ensuite, il suffit de laisser le garbage collector de faire son travail. Il est presque jamais une bonne idée d'appeler GC.Collect() explicitement, de vous-même et il pourrait même ne pas faire ce que vous voulez/besoin d ' /attendre et de vous coûter la performance. L'Analyse statique de Code (=FxCop) ne vous avertit avec La fiabilité de la règle CA2001 sur cela pour rien, vous savez? Il suffit de ne pas le faire sauf si vous savez vraiment ce que vous faites. Et même alors, ne pas le faire. 😉

    Êtes-vous sûr que le dictionnaire est énorme? N'est-il pas juste 10 Mo de mémoire et le reste est pris par votre application? Question qui pourrait vous aider: Avez-vous utilisé un profiler encore de voir où la mémoire est effectivement consommée...?

    • Le dictionnaire est que les grandes. Quand j'ai couru le code avec le .Changement clairs, l'utilisation de la mémoire va de 160 mo à 50 mo. Donc je suppose que le dictionnaire est 110mb.
    InformationsquelleAutor peSHIr
  5. 1

    Edit:

    Pour être juste, la définition de la référence à la valeur null ne libère pas la mémoire, il attribue à son conteneur à une adresse différente, dans ce cas, la valeur null. Selon MSDN, appelant Clear(), fait ceci: "Le Comte de la propriété est définie sur 0, et des références à d'autres objets à partir d'éléments de la collection sont également libérés. La capacité reste inchangée."

    ...

    Vous devriez ne jamais appeler le garbage collector. Vous utilisez des objets gérés sans ressources autochtones, la confiance, la collecte des déchets à nettoyer après vous.

    En fonction de la taille de votre dictionnaire, vous n'avez pas besoin de vous soucier de mémoire, la mémoire n'est pas votre problème, c'est les éboueurs problème.

    Appel Clear() va supprimer les références à tout objet contenu à l'intérieur, mais la capacité reste inchangé.

    Sur une note plus technique, la collecte de la mémoire est cher et beaucoup de temps d'exploitation. Raison d'être, non seulement le GC poignée de segment de mémoire et de nettoyer votre tas, elle aussi défragmente le tas. Il tente de passer de la mémoire en blocs contigus à la vitesse maximum de l'allocation pour quand un morceau de code fait une demande importante.

    p.s. Quelle est la taille de votre dictionnaire que vous utilisez 155MB de la mémoire?

    • Son grand, je suis concilier un million de transactions.
    • holy crap qui est un grand nombre de transactions. Je suppose que c'est une chose, ou vous avez besoin de le faire régulièrement?
    • Une fois par jour, tous les jours.
    • En fait je me suis trompe - environ une demi-douzaine de fois chaque jour.
    • OK, si c'est le cas, est-il une raison pour laquelle il doit être fait dans le code? Pourquoi ne pas simplement utiliser la base de données pour traiter ces transactions, est-il une raison de ne pas le faire?
    InformationsquelleAutor Chris
  6. 1

    Vous avez besoin de la mémoire? Le mémoire est disponible, c'est juste pas être récupérée. Vous ne devez pas effacer le dictionnaire, tenir une référence faible et de laisser l'exécution faire son travail.

    Si vous voulez voir de très profond dans ce qui se passe, consultez la .NET Memory Profiler. Qui va vous donner de la visibilité dans exactement ce qui se passe avec votre objet, ce que génération c'est ce que la mémoire est utilisée par les ce et sur et sur. 🙂

    • Je n'ai pas besoin de la mémoire, mais dans notre situation, je préfère remettre les OS rapidement, si possible. Je pense que cette question est de plus en plus théorique "comment faire?" plutôt que "j'ai vraiment besoin de faire cette chose"...
    InformationsquelleAutor JP Alioto
  7. 1

    Ok, j'ai une théorie là...
    Le dictionnaire est une collection de KeyValuePair qui est encore une fois un type de référence.

    Votre dictionnaire contient ces keyValuePairs. Quand vous dites:

    Txns = null

    Il libère la référence "Txns" de ceux KeyValuePair collection. Mais encore la mémoire réelle de 150 Mo est référencé par ceux KeyValuePair et ils sont dans le champ d'application, ce n'est pas prêt pour la collecte des ordures.

    Mais lorsque vous utilisez la commande suivante:

    Txns.Clear();
Txns = null;
GC.Collect();

    Ici, la méthode clear libère également l'150 mo de données à partir de leurs propres KeyValuePair les références de l'objet. Ainsi, ces objets étaient prêts pour la collecte des ordures.

    C'est juste un sauvage suppose que je fais ici. Les commentaires sont les bienvenus 🙂

    • Le KeyValuePairs ne sont pas dans le champ d'application. Pour les avoir à portée, vous devez configurer des variables supplémentaires ou un tableau pour stocker des copies de la KeyValuePairs, similaire à ceci: var arrayOfReferencesToKeyValuePairs = Txns.ToArray(); Dans son scénario, une fois Txns est null, il n'y a aucun moyen d'accéder à de l'KeyValuePairs et le garbage collector le voit.
    InformationsquelleAutor Savaratkar
  8. 0

    Windows a deux la mémoire des événements de disponibilité. Je m'attends à de la CLR pour répondre à cette question. Si il y a suffisamment de mémoire disponible, la chose la plus intelligente est de ne PAS courir le garbage collector. Donc, assurez-vous que vous êtes, en effet, l'observation de mauvais CLR comportement, veuillez répéter le test avec une autre application factice à l'aide d'un gros tas de mémoire.

    InformationsquelleAutor MSalters
  9. -1

    Il n'est généralement pas une bonne idée d'essayer de forcer la GC. Avez-vous vraiment besoin de l'ensemble de dictionnaire en mémoire?

    • Bonne question. Peut être un problème de conception.
    • Oui j'en ai besoin, est pour une grande réconciliation (comparer les lignes d'un tableau à l'autre). 150 mo est peanuts.
    • 150 mo est à peine arachides. Si vous en avez vraiment besoin, c'est très bien et dandy, mais une bonne majorité du temps, ce genre de déclaration implique une sorte de problème de conception ou de l'ignorance d'une meilleure façon de le faire. Je veux dire que, comme aucune insulte, juste un constat.
    • Vers le bas-droit de vote parce que ce devrait être un commentaire. Il ne répond pas à la question ou de fournir un aperçu sur le problème réel.
    InformationsquelleAutor ivmos