Discussion :

[tupac25]

Bonjour,

J'ai développé une application devant tourner en tache de fond sur un pc sans interruption. Pour cela, il me faut gérer correctement la mémoire de celle ci.

Voici grosso modo, ce que contient mon application:
-Une interface graphique dynamique avec 2 JfreeChart et un jtable.
-Plusieurs thread ayant chacun une connexion JMS.
-7 Timers pouvant tourner simultanémenet.

Je pense avoir cité les objets utilisant le plus de ressource.

J'ai remarqué que depuis que j'ai mi en place les timers, mon application est devenu beaucoup plus gourmande en mémoire. J'utiliise Jconsole pour mes tests de mémoire.

Avez vous quelques conseils à me donner pour la gestion de la mémoire?

PS: j'ai déja parcouru les tuto sur ce sujet.

[Pill_S]

y'a pas de miracles, pour gérer correctement la mémoire:

1) fermer manuellement dans un finally toutes les ressources systèmes (flux, connexions, ...)
2) dès qu'un objet n'est plus utile, on met sa référence à null (principalement les champs de classe, les variables locales étant automatiquement détruites)
3) on profile avec un profiler (de préférence plus évolué que jconsole) et on interprète les résultats: on regarde les allocations, on exécute le garbage collector, et on voit quelles sont les objets qui n'ont pas pu être collectés

c'est pas très facile, mais y'a rien d'autre en magasin

[tupac25]

Est ce que Java VisualVM est plus évolué que JConsole?

[adiGuba]

Salut,

2) dès qu'un objet n'est plus utile, on met sa référence à null (principalement les champs de classe, les variables locales étant automatiquement détruites)

Mais si on a besoin de mettre à null un attribut de classe c'est qu'il y a un soucis : cela ne devrait pas être un attribut mais une variable locale...

Une erreur fréquente étant de tout mettre en attribut (voir en static) par "simplicité".

a++

[Invité]

Est ce que Java VisualVM est plus évolué que JConsole?

Oui en effet.
Entre autres, avec Visual VM on peut observer la mémoire et les processus en détail au runtime.

[Pill_S]

Mais si on a besoin de mettre à null un attribut de classe c'est qu'il y a un soucis : cela ne devrait pas être un attribut mais une variable locale...

+1, mais par principe je rappelle la règle: il y a certains cas où cela peut s'envisager (p.ex. mise en cache d'un résultat quelconque jusqu'à ce qu'on l'invalide en le mettant à null, ou suppression d'un objet d'un ThreadLocal lorsqu'on sait que le thread va mourir, etc)

[tupac25]

Est ce que cette déclaration est mauvaise alors:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Class MaClass{
 
  private Object obj = null;
 
  public void method(){
 
     obj = new Object();
  }
}

Sachant que je n'ai pas besoin que mon objet soit global.

[adiGuba]

@tupac25 question : a quoi sert 'obj' ???

Sans la réponse à cette question, impossible de t'en dire plus...

a++

[tupac25]

Disons que obj est une classe à laquelle je fais un unique appel et dont je n'ai plus besoin par la suite.

[adiGuba]

Dans ce cas pose-toi cette question : quel intérêt y-a-t-il à conserver cet objet en attribut d'instance, alors que tu ne t'en sers que localement.

Bref cela devrait être un paramètre locale de la méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Class MaClass{
  public void method(){
     Object obj = new Object();
  }
}

Ce qui facilite le travail de tout le monde et c'est tout bénef :

• Le développeur sait qu'il s'agit d'une variable locale uniquement. Pas besoin de pourrir les attributs de la classe avec 150 attributs inutile.
• Le GC sait qu'il s'agit d'un objet temporaire, qu'il pourra nettoyer rapidement.
• La JVM sait qu'il s'agit d'une variable locale, qui ne sera jamais null ni jamais modifié par un autre thread, et peut donc optimiser ses accès en conséquence.

a++

[tupac25]

Merci! Je vais devoir faire un grand nettoyage de mon code alors. J'ai pris l'habitude de déclarer toutes mes classes en attribut de classe... je trouvais cela plus lisible...

Et c'est la premiere fois que je dois faire attention à la gestion de la mémoire donc je pense qu'il y a pas mal de point qu'il va falloir que je revoie.

Sinon est ce que les Timer sont gourmant en mémoire? j'ai remarqué une grosse augmentation en ressource depuis que je les ai ajouté à mon code.

[adiGuba]

Un timer en lui même ne représente pas grand chose...

C'est son traitement qu'il faut voir. S'ils manipulent des données lourdes et comment...


a++

[tupac25]

C'est un Timer avec une période hebdomadaire soit 604 800 000 milliseconde mais le traitement réalisé est très lègé. Le problème doit venir d'autre chose alors.

EDIT:
Après plusieurs heures de test voici ce qui en ressort:
Le nombre de classe n'évolue pas, il reste stabel.
Le nombre de thread régulier.
L'usage du CPU ne depasse pas 3%
Heap size et used heap sont regulier aussi mais je remarque de forte augmentation des que je modifie la taille de ma fenetre.

Je pense que les 3 premiers points sont positifs mais pour le Heap size je dois avoir un petit probleme. Lorsque j'ai de net augmentation, elle ne diminue pas ensuite et garde la valeur max qu'elle a eu. Après plusieurs modification de la taille de ma fenêtre, l'application devient trop gourmande.

Est ce que cela est du à un mauvais développement de ma GUI?