Discussion :

[kZn.13]

Bonjour,

question bête :

Si on ajoute un objet dans une collection, puis si on le supprime en faisant objet.finalize(); cela le supprime-t-il aussi de la collection?

Merci

[gifffftane]

Non.

La méthode finalize ne sert à rien, qu'à embrouiller le bon peuple des programmeurs et des programmeuses.

[kZn.13]

Ah bon? Donc pour vraiment détruire un objet comment tu fais?

[Tommy31]

Tu fais rien.

Si les objets de la collection ne sont réellement plus utilisés (plus référencés) ils seront détruits automatiquement.

[gifffftane]

Oui, par rapport à ta collection il suffit de faire collec.remove(tonObjet), et si cet objet n'est référencé nulle part ailleurs, alors le ramasse miette le nettoiera de la mémoire à l'occasion.

[OButterlin]

Ceci dit, la méthode finalize n'est pas totalement injustifiée.
Si l'objet contient des références sur des fichiers (par exemple), cette méthode permettra de libérer les ressources.
Sinon, pour le reste, c'est tout à fait ça, tu ne maîtrises pas la mémoire utilisée par un objet, ni le moment où elle sera libérée une fois éligible au Garbage Collector. Le fait de l'appeler (System.gc() n'y change pas grand chose d'ailleurs...

A+

[kZn.13]

Ben merci

[gifffftane]

Pour compléter sur finalize, depuis l'arrivée des WeakReference, sa nécessité d'usage se réduit aux cas tordus.

Par exemple pour les fichiers, en quoi est-ce nécessaire d'utiliser cette méthode ? close() ne suffit pas ? Ou dans la conception d'une classe qui contient en interne des ressources à libérer, on ne peut pas créer une méthode style dispose(), que l'on demande d'appeler explicitement, comme on le fait pour Frame, Graphics, et tant d'autres choses ?

Des explications plus complètes à How to Handle Java Finalization's Memory-Retention Issues.

[marchand_de_sable]

Si les objets de la collection ne sont réellement plus utilisés (plus référencés) ils seront détruits automatiquement

Question bête : si l'objet est toujours présent dans une Collection, il y est donc référencé, non ?
Donc le GC ne le supprimera pas de la mémoire. Si ?

[gifffftane]

Oui, non.

[marchand_de_sable]

Oui, non.

Heu, donc j'ai bon ??
si l'object est toujours dans la Collection, il y est référencé, donc il ne sera pas supprimé par le GC.

D'où la nécessité de faire le collec.remove(obj), en le mettant, à la limite, dans le finalize()....

[adiGuba]

Salut,

Heu, donc j'ai bon ??
si l'object est toujours dans la Collection, il y est référencé, donc il ne sera pas supprimé par le GC.

Oui c'est exactement ca : un objet ne peut être libéré par le GC qu'à partir du moment où il n'est plus référencé nulle part (en tout cas pour les références "fortes" - il y a des cas particulier avec les autres types de référence : http://blog.developpez.com/adiguba?t...rences_en_java)

D'où la nécessité de faire le collec.remove(obj), en le mettant, à la limite, dans le finalize()....

NON pas dans le finalize() !
finalize() ne doit pas être appelé explicitement. Cette méthode est appelé par le GC une fois qu'il a décidé que l'objet pouvait être libéré. Tu n'as pas à l'appeler directement !
Donc si tu rentres dans finalize() cela veut dire que ton objet a déjà été supprimé de la collection...

De plus je ne trouve pas que ce soit très correct que ce soit l'objet lui-même qui s'enlève de la collection


finalize() n'a pas à être utilisée pour gérer la mémoire : c'est le rôle du GC.
finalize() est conçu pour libérer les ressources externes non gérées par le GC !

Par exemple pour les fichiers, en quoi est-ce nécessaire d'utiliser cette méthode ? close() ne suffit pas ?

close() (ou une méthode de libération) est amplement suffisant dans tous les cas, mais finalize() est un garde-fou au cas où close() ne serait pas appelée... ceci afin d'éviter de conserver la ressource infiniment (en particulier sur une application serveur).



a++