Libération objet complexe

Version imprimable

20/05/2011, 19h00
Guybrush

Libération objet complexe

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 ?
23/05/2011, 13h17
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...
23/05/2011, 13h40
-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.
23/05/2011, 14h01
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é.
23/05/2011, 15h57
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...
24/05/2011, 11h41
-gma-

Citation:

Envoyé par Nemek

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().

Citation:

Envoyé par Nemek

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.
24/05/2011, 12h14
Logan Mauzaize

Citation:

Envoyé par -gma-

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.

Citation:

Envoyé par -gma-

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.

Citation:

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.
24/05/2011, 13h45
-gma-

Citation:

Envoyé par Nemek

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

Citation:

The Java programming language does not guarantee which thread will invoke the finalize method for any given object.

source

Citation:

Envoyé par Nemek

Dans ce cas, les PhantomReference sont plus appropriées.

Je ne vois pas la plus-value d'avoir des Phantom dans ce cas précis alors qu'on peut utiliser les Weak qui sont déjà là, puisque elles seront toutes effacées avant d'être mises dans la Queue.

Citation:

Envoyé par Nemek

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).

C'est la seule solution qui me vient aussi à l'idée, mais si quelqu'un connait une autre solution ça m'intéresse. Même si ça paraît tordu c'est justifié par ta citation de la javadoc.