Libérer les ressouces en C#

Version imprimable

08/08/2008, 10h24
Philorix

Libérer les ressouces en C#

Bonjour,

Je débute en C#, bien que je connaisse et pratique d'autres langages.

J'ai tendance à vouloir dés-instancier les ressources et object en appelant la méthode Dispose() et en mettant mes variables à null, mais je ne retrouve pas cette manière de coder en regardant les exemples de code ici ou là.

Je me pose donc une question, ai je raison de faire cela ou c'est complètement inutile voir générateur de bug ???

Merci pour votre aide…
08/08/2008, 10h29
SaumonAgile

Ce n'est pas une mauvaise pratique d'appeler Dispose sur les objets implémentant IDisposable, au contraire. Cela facilite le travail du garbage collector.
08/08/2008, 11h15
Pol63

les classes manipulant des objets non managés (appartenant à l'OS par exemple, donc que .net n'a pas accès à l'emplacement mémoire de ces objets) implémentent la méthode dispose qui détruit ces objets en question (image, base de données etc...)

quand une variable est hors de portée (par exemple une sub se fini, tous les varaibles créées dans cette sub sont mises à null, les objets restants dans leur espace mémoire quand meme)

une instance mise à null met à null toutes ses variables de la meme manière

le garbage collector cherche les objets non référencés par quelqu'un d'autre
il appelle la méthode finalize sur ces objets (pour les objets implémentant la méthode dispose, finalize appelle la méthode dispose)
puis il supprime l'objet de l'emplacement mémoire

la mémoire est donc libérer toute seule par le garbage collector et on est pas obligé de se poser la question de comment marche la gestion de la mémoire

par contre il est recommandé d'appeler dispose quand on a plus besoin d'un objet, ca vide la partie non managé de la mémoire tout de suite au moins (using/end using est pas mal pour ca)

le garbage collector fait pas forcément le ménage souvent ... en général quand l'os lui dit que l'appli commence à etre encombrante au vue de la RAM dispo sur le pc
08/08/2008, 11h41
olibara

Merci a Philorix pour cette excellente question qui a généré des réponses non moins pertinentes

Etant moi meme un routier du C j'ai aussi l'habitude de faire mes calloc malloc et les free moi meme et de gerer tout ca le plus proprement possible.

En C# je me demande aussi souvent jusqu'ou on peut ou on doit courrir dans les pieds de la ménagère pour avoir un travail bien fait mais sans trop la bousculer !!

Citation:

Envoyé par Philorix

mais je ne retrouve pas cette manière de coder en regardant les exemples de code ici ou là.

1. L'utilisateur n'a pas besoin d'appeler la méthode Dispose() si le pattern a été correctement mis en place mais c'est au Garbage Collector de l'appeler et ça prends du temps. Il faut désallouer le plus souvent possible pour ne pas obliger le GC à le faire afin de ne pas le surcharger. Le GC a une influence sur les performance ce n'est pas négligeable.

2. Si tu 'as pas vu d'appel de la méthode Dispose dans du code c'est probablement que le programmeur a utilisé l'instruction suivante:
Code:

1 2 3 4 using(ObjetImplementantDispose objet = new ObjetImplementantDispose() { //Instructions }
En fait l'instructions using elle va appeler automatiquement la méthode Dispose en suivant ce principe:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 ObjetImplementantDispose objet = new ObjetImplementantDispose();; try { //Instructions } finally { IDisposable dispose = objet as IDisposable; if(dispose != null) objet.Dispose(); }
D'une manière ou une autre la méthode Dispose sera appelée, ce qui incombe au développeur de l'appeler explicitement.

08/08/2008, 14h48
SaumonAgile

Juste pour réagir à ce que disait harz62, à ma connaissance, le GC n'appelle pas Dispose. Au mieux il demande au finalizer d'appeler la méthode Finalize d'un objet si ce dernier en possède une.
Par contre Dispose doit être définie de sorte que lorsqu'elle est appelée, elle supprime la nécessité d'appeler cette méthode Finalize.

En gros, pour résumer :
- la méthode Finalize (si elle existe) est appelée par le GC de manière non déterministe et sert à libérer les ressources d'un objet.
- la méthode Dispose est appelée par l'utilisateur pour libérer les ressources de manière déterministe. Quand elle est appelée, elle doit appeler GC.SuppressFinalize(this); pour que le GC n'appelle pas automatiquement la méthode Finalize (vu que les ressources ont déjà été libérées).

En pratique, la méthode Finalize appelle la méthode Dispose pour factoriser le code. Voici l'implémentation recommandée de IDisposable : http://msdn.microsoft.com/en-us/libr...isposable.aspx
08/08/2008, 15h27
Guulh

Citation:

Envoyé par sperot51

une instance mise à null met à null toutes ses variables de la meme manière

Plait-il ? :) Que veux-tu dire ?
08/08/2008, 16h39
harz62

Citation:

Envoyé par SaumonAgile

Juste pour réagir à ce que disait harz62, à ma connaissance, le GC n'appelle pas Dispose. Au mieux il demande au finalizer d'appeler la méthode Finalize d'un objet si ce dernier en possède une.
Par contre Dispose doit être définie de sorte que lorsqu'elle est appelée, elle supprime la nécessité d'appeler cette méthode Finalize.

C'est vrai j'ai n'ai pas été assez précis dans mes explications, je vais reprendre le cas ou l'utilisateur n'appelle pas la Méthode Dispose()

Le GC appelle le finaliseur (comme tu l'a dit) qui est représenté par le code en tant que syntaxe d'un destructeur qui lui même appelle la méthode virtuelle protégée Dispose (c'est une surcharge de la méthode publique, elle prend en paramètre un booléen qui détermine si c'est l'utilisateur ou le finaliseur qui appelle la méthode, elle peut donc réagir en conséquence).

L'implémentation de la surcharge protégée de Dispose n'est pas obligatoire je pense mais fortement recommandée.

Pour résumer, il y a 2 méthodes Dispose (c'est cela que je n'ai pas précisé)
- La méthode protégée virtuelle Dispose avec un paramètre booléen appelée par le finaliseur OU par la méthode publique Dispose.
- La méthode publique Dispose sans paramètre destinée à être appelée UNIQUEMENT par le développeur.
08/08/2008, 19h03
Pol63

et tout ceci est écrit noir sur blanc dans msdn ^^

j'ajouterais aussi que finalize existe sur object donc il est partout, les classes de microsoft ayant un dispose l'appelle dans finalize

et beaucoup de classes microsoft font gc.supressfinalize(me) dans le constructeur vu que finalize est une méthode couteuse en ressources pour le gc

Citation:

Envoyé par Guulh

Plait-il ? :) Que veux-tu dire ?

une classe qui comporte des variables
si j'ai une instance de type classe que je met à null, les variables définies dans cette classe pour cette instance sont mises à null par le framework, certes c'est pas écrit ca dans msdn mais on avait fait quelques tests et puis ca parrait logique, y en a plus besoin ...
08/08/2008, 20h08
Guulh

Citation:

Envoyé par sperot51

une classe qui comporte des variables
si j'ai une instance de type classe que je met à null, les variables définies dans cette classe pour cette instance sont mises à null par le framework, certes c'est pas écrit ca dans msdn mais on avait fait quelques tests et puis ca parrait logique, y en a plus besoin ...

Non. Quand on affecte une reference a null, on ne fait rien d'autre que mettre une reference a null. L'objet precedemment pointe par cette reference n'est absolument pas impacté, d'autant plus qu'il peut tout a fait avoir d'autres references qui lui pointent dessus. C'est juste que le GC, quand l'envie l'en prendra, supprimera de la memoire tous les objets morts, c'est a dire qui ne sont plus reference par des objets vivants.

Pour en avoir le coeur net, y a qu'à tester...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
        class Toto
        {
            public object Titi = new object();
        }
 
        private static void TestNull()
        {
            Toto toto = new Toto();
            WeakReference wr = new WeakReference(toto);
            toto = null;
            if (wr.IsAlive)
            {
                Toto toto2 = wr.Target as Toto;
                if (toto2.Titi == null)
                {
                    Console.WriteLine("toto2.Titi == null => sperot51 a raison !");
                }
                else
                {
                    Console.WriteLine("toto2.Titi != null => Guulh a raison !");
                }
            }
        }

La sortie de ce programme est la suivante :

Citation:

toto2.Titi != null => Guulh a raison !

Et heureusement d'ailleurs, car comme dit Guulh il peut très bien rester d'autres références vers l'objet...

08/08/2008, 21h36
Pol63

ah oui en effet je dis nimp

avec un peu de chance je voulais dire que c'est au moment de la destruction de l'objet par le gc

parce que lors de mes tests de l'époque avec des espions je m'étais retrouvé avec des booléen qui valent false alors qu'ils valaint true, ils restent en effet accessibles étant par valeur alors que tout le reste disait echec de l'évaluation
08/08/2008, 23h00
SaumonAgile

Citation:

Envoyé par sperot51

parce que lors de mes tests de l'époque avec des espions je m'étais retrouvé avec des booléen qui valent false alors qu'ils valaint true, ils restent en effet accessibles étant par valeur alors que tout le reste disait echec de l'évaluation

Les booléens ainsi que tous les types valeurs (types primitifs, structures, etc) ne sont pas gérés par le GC, ils sont créés sur la pile et libérés dès qu'ils sortent du scope (de la fonction, du bloc, de la structure, etc). C'est pour ça que tu n'as pas le même fonctionnement que les types références qui eux sont gérés par le GC. Et encore c'est un raccourci. Le GC gère les objets pas les références. Mettre une référence à null ne fait que supprimer un lien vers un objet dans la mémoire. Un objet sans référence est éligible pour la récupération (par le GC).
14/08/2008, 18h46
Philorix

Merci pour ces pertinentes infos !