Discussion :

[dahtah]

Bonjour à tous,
je voulais juste savoir quelles étaient les techniques à éviter pour ne pas avoir de fuite de mémoire (en particulier dans la gestion des threads) ?
Merci.

[TabrisLeFol]

Il n'y a pas de fuite puisqu'il y a le garbage collector. Mais une utilisation raisonnée de la memoire peut en effet augmenter les performances.

[CyberChouan]

Une fuite de mémoire, ça se produit en java quand tu gardes des références sur un objet temporaire qui n'est plus utilisé...

En temps normal, il n'y en a pas... mais si tu veux t'en assurer, à la fin de ton traitement, tu forces toutes les variables que tu soupçonnes de pouvoir en provoquer à 'null'. Cela indiquera automatiquement au ramasse-miettes qu'il peut récupérer la mémoire correspondante.

Sinon, JProbe est un bon outil pour détecter et résoudre les problèmes de fuite mémoire... mais il coute un peu cher

[dahtah]

Je prend un exemple extrême :
Une boucle while dans un thread ne crée pas de fuite mémoire? Le Gc ne peut jamais faire son travail...

[adiGuba]

Salut,

Je prend un exemple extrême :
Une boucle while dans un thread ne crée pas de fuite mémoire? Le Gc ne peut jamais faire son travail...

Tu veux parler d'une boucle infini je pense ?

Dans ce cas on ne peut pas parler de fuite de mémoire puisque les objets sont toujours utilisés par le thread en question...


La plupart des fuites de mémoire sont dû soit à des objets stocké dans des collections static ou valide toute la durée de l'application sans jamais y être supprimé, soit à l'utilisation de resource non géré par le GC qui ne serait pas proprement libéré (les flux ou socket pas fermés par exemple).

a++

[dahtah]

d'accord.
Je parlai bien d'une boucle infinie.
Pour résumer, éviter de déclarer les variables en static (toujours utiliser des accesseurs et mutateurs donc?) et toujours libérer les flux et sockets.
Ne pas monopoliser un objet.
Pour le reste le Gc s'en charge.
Si l'on est obligé d'utiliser une de ces méthodes, est-ce une bonne solution de forcer le passage du Gc?
Merci à tous

[adiGuba]

Pour résumer, éviter de déclarer les variables en static

Pas forcément : mais un objet static sera présent pendant toutes la durée de l'application ! Il faut donc éviter d'y mettre l'image de 5 Mo du SplashScreen de démarrage

(toujours utiliser des accesseurs et mutateurs donc?) et toujours libérer les flux et sockets.
Ne pas monopoliser un objet.
Pour le reste le Gc s'en charge.

Oui...
Pour la libération des flux penser à utiliser des bloc finally...

Si l'on est obligé d'utiliser une de ces méthodes, est-ce une bonne solution de forcer le passage du Gc?

Non non et non : dans ce sujet tu peux voir que l'appel explicite du GC provoque de grosses pertes de performances : Difference de performances Unix/Windows d'un programme?

a++