Discussion :

[Guybrush]

Dans mon application, je créé des objets "complexes" qui maintiennent ouvertes entre autres des connexions à des sockets. Je ne souhaite pas conserver ces connexion ouvertes durant toute la durée de la vie de l'application (qui peut être très longue) et je souhaiterais donc les fermer lorsque l'objet en question n'est plus utilisé. Or je ne peux pas connaitre à l'avance la durée de vie de mon objet. J'ai encapsulé mon objet dans une WeakReference afin qu'il soit nettoyé lorsqu'il n'est plus référencé mais j'aimerais être "notifié" à la destruction de l'objet pour piuvoir faire les nettoyages nécessaire et en particulier fermer les connexions.
Je sais qu'il n'est pas conseillé de surcharger la méthode finalize et j'ai sait également qu'il existe les PhantomReference qui permette ce genre de choses mais :
1- Peut on combiner Phantom et Weak reference ?
2- Je n'ai pas réussit à faire fonctionner les PhantomReference pour être systématiquement notifié à la destruction.

Quelqu'un aurait-il un cas d'utilisation pratique à me fournir ?

[NicoL__]

Une idée serait peut-être de gérer ta connexion dans un singleton et de l'associer à tes objets complexes. En suite de gérer l'ouverture et la fermeture des connexions au plus près des besoins, de fermer dès que chaque opération unitaire est réalisée et de rouvrir pour refaire un appel.
De toute les façon le serveur va fermer ses connexions au bout d'un certain temps d'inactivité. Le risque est que ton objet complexe se "réveil" pour faire une action et que sa connexion soit déjà fermer par le serveur.
A moins que tu es un besoin particulier du genre reverse ajax...

[-gma-]

Si tu as déjà des WeakReference, ce n'est pas forcément la peine d'aller plus loin avec des PhantomReference. Il suffirait d'utiliser une ReferenceQueue à passer paramètre du constructeur de la référence. Et lorsque la méthode remove() de la queue retourne une référence alors tu peux fermer la connexion correspondante.

Attention quand même, avec une WeakReference, tu dépends du garbage collector et tu n'as jamais de garantie sur le moment où il décidera qu'il peut "nettoyer" cette référence.

[Logan Mauzaize]

Utilisez une ReferenceQueue ou surcharger finalize ça revient à peu de choses près au même.

Sauf que :

• finalize() est appelée quand l'objet est vraiment libéré
• La reference queue est notifiée quand la reference detecte la perte et non sur la libration de l'objet. Par exemple pour une WeakReference, il peut y avoir des PhantomReference qui maintienne toujours l'objet en mémoire.
• Quand la reference queue est notifiée, tu as perdu l'objet

Dans un premier temps, j'écrirais une méthode stop/shutdown/clean qui fais le ménage proprement (ne le fais pas s'il est déjà fait). Je redéfinirai "finalize()" afin qu'il fasse le appel à cette méthode.

Dans un second temps je reverrai mon architecture pour être notifié du moment où le service doit être arrêté.

[NicoL__]

L’intérêt de close est d'optimiser la gestion des ressources par rapport au garbage. Si tu perds la référence de ton objet complexe (la chaine de strong référence est brisée), que la soket est uniquement référencée par cet objet, et que le garbage passe, le garbage va ramesser ta socket. Si c'est l'implémentation standard, ne t'inquiète pas tout est gérer.
Les weakreference c'est pour éviter de créer une chaine de strong références et ainsi garder un référence "weak" tout en permettant au garbage de détruire tes objets.
Si tes sockets sont partagées entre tes objets complexes, que tu multi thread alors je dirais qu'il vaut mieux créer un pool de socket, ça sera le plus économique q'une socket par objet complexe. Sinon une socket pour tous tes objets...

[-gma-]

finalize() est appelée quand l'objet est vraiment libéré

Et on ne contrôle pas le thread dans lequel finalize() est appelé, ce qui peut être parfois gênant selon ce qu'on y fait. En plus on peut toujours ressusciter l'objet dans le finalize().

La reference queue est notifiée quand la reference detecte la perte et non sur la libration de l'objet. Par exemple pour une WeakReference, il peut y avoir des PhantomReference qui maintienne toujours l'objet en mémoire.

Oui mais on ne peut pas accéder à l'objet via une PhantomReference donc il n'y a pas de raison qu'il soit utilisé par le programme.

[Logan Mauzaize]

Et on ne contrôle pas le thread dans lequel finalize() est appelé, ce qui peut être parfois gênant selon ce qu'on y fait. En plus on peut toujours ressusciter l'objet dans le finalize().

Je mettrais ma main à couper qu'il s'agit de Finalizer mais je peux me tromper.

Oui mais on ne peut pas accéder à l'objet via une PhantomReference donc il n'y a pas de raison qu'il soit utilisé par le programme.

Phantom references are most often used for scheduling pre-mortem cleanup actions

source
Dans ce cas, les PhantomReference sont plus appropriées.
D'une manière comme d'une autre les informations ne sont plus accessibles alors je vois pas ce que tu pourrais y faire.
Sauf si tu stockes toutes les informations dans une IdentityHashMap sur la référence (Phantom ou Weak).

De toutes façons l'idéal reste de gérer proprement ses ressources : les nettoyer dès qu'on en a plus besoin.
Car le principe du général du GC, c'est qu'il fait le ménage quand la JVM a besoin de mémoire.