Allocation Memoire et stratégie de déréférencement

Version imprimable

05/10/2009, 15h42
william44290

Allocation Memoire et stratégie de déréférencement

J'ai été confronté à un problème de mémoire (Occupation cumulative de la mémoire jusqu'a HeapStack).

Schématiquement mes composants n'étaient pas ramassés car des références persistaient dans des ArrayList,
ou des class de service étaient référencées dans des PropertyChangeListener.

Bref après analyse du code et utilisation de jconsole et MAP je me suis résolus à coder un mécanisme de déréférencement des composants et des class de services.

J'ai implémenté une méthode dispose() pour tous ces objets ainsi que la méthode finalize().

Les méthodes dispose() sont appelés en cascade et de manière hiérarchique.
Les Méthodes finalize() moucharde la destruction réelle des objets lors du déclenchement du Gc.

Questions :
Est-ce la bonne solution ?
Avez-vous été confronté à ce type de problème ?
Comment l'avez vous résolus ?
J'utilise 2 polices avec une dizaine de taille celles-ci prennent environ 1Mo de mémoire soit 45% de la mémoire disponible initialement. peut-on réduire cette occupation ?

Merci de vos réponses.
05/10/2009, 16h09
adiGuba

Citation:

Envoyé par william44290

Schématiquement mes composants n'étaient pas ramassés car des références persistaient dans des ArrayList,

Pourquoi était-il stocker dans des listes ????

Citation:

Envoyé par william44290

ou des class de service étaient référencées dans des PropertyChangeListener.

Si ta classes est référencé comme listener sur un composant existant, alors c'est normal que le GC ne la détruise pas puisqu'il est toujours valide.

Citation:

Envoyé par william44290

Les Méthodes finalize() moucharde la destruction réelle des objets lors du déclenchement du Gc.

Attention car finalize() peut retarder le processus de libération...

Citation:

Envoyé par william44290

Est-ce la bonne solution ?

Il faudrait d'abord éviter de stocker des éléments "temporaires" dans des listes "globales" :arrow: Pourquoi fait-tu cela ?

Plus généralement il faut essayer de limiter au maximum le scope des références, afin de faciliter le travail du GC.

a++
05/10/2009, 16h27
william44290

J'ulise des listes de composants dans le cadre d'un frameWork.

Structurellement j'ai N class métier ou j'instancie des composants et je valorise des property.(d'un coté)

(et de l'autre) une class de service qui peut parcourir une liste de composants pour gérer leurs apparences en fonction d'un context ou traiter le contrôle de saisie ou bien encore la circulation du focus par exemple.

J'ai développé un JTable générique. il me suffit d'ajouter un composant dans sa liste d'édition pour que la colonne devienne éditable. Le code du JTable n'est jamais modifié mais c'est la fiche métier qui détermine quelles colonnes seront éditables. Idem pour l'ordonnancement, la présence ou pas d'une colonne dans la liste.