gestion de la memoire en java

bonjours,
Je me pose quelques petites questions sur la gestion des objets java en memoire et notement lorsque dans une boucle while on fait un new que deviennent les objets anterieurement crees avec le new, sont-ils detruit par le garbage collector, ou alors restent ils en memoire??? :

Code:

---

1 2 3 4 5

while(true) { classA ob1=new classA;   }

---

à l'itération suivante les objets deviennent Zombie et, en temps utile, pourront être récupérés par le glaneur de mémoire.

En théorie, tu n'as pas besoin de te soucier de la mémoire et des zombies en java.

En pratique, si tu ne veux pas faire fondre ton pc, ne fait jamais ce genre de choses.

Essaye de réutiliser au maximum les variables, de faire le moins de new possible etc..

l'idéal pour un cas comme ça serait qqch comme :

Code:

---

1 2 3 4 5 6 7

classA ob1=new classA; while (true) { ob1.init(valeur que tu aurais mis dans le new) ... }

---

Et dans ton init, tu nettoies et tu réutilises.

Salut,

Si je ne dis pas de betise, tu peux aussi assigner ta variable inutilisée à null, ca t'évitera d'avoir de "gros" objets zombies (utile essentiellement dans le cas ou tu as de grosses montées en charge mais la méthode de Faiche me semble la mieux)

++

Pour compléter :

Un objet est potentiellement détruit de la mémoire (si le garbage collector passe par là) s'il n'y a plus aucune référence à cet objet (en gros)

Dans ton exemple ton objet est créé dans le bloc du while. ob1 n'existe que dans ce bloc, ce qui signifie que l'objet qu'il réfère est éligible pour le garbage collector une fois arrivé à la fin du while.
Cet exemple ne pose pas un problème de mémoire mais de performance car un nouvel objet est créé à chaque fois.


De manière général, en cas de doute sur le référencement des objets, faire un petit ob1=null quand on en a plus besoin peut améliorer la gestion de la mémoire, car l'objet (s'il n'est référencé nulle part ailleurs) devient allors éligible pour le gc.

Citation:

---

Envoyé par Faiche

En théorie, tu n'as pas besoin de te soucier de la mémoire et des zombies en java.

En pratique, si tu ne veux pas faire fondre ton pc, ne fait jamais ce genre de choses.

Essaye de réutiliser au maximum les variables, de faire le moins de new possible etc..

l'idéal pour un cas comme ça serait qqch comme :

Code:

---

1 2 3 4 5 6 7

classA ob1=new classA; while (true) { ob1.init(valeur que tu aurais mis dans le new) ... }

---

Et dans ton init, tu nettoies et tu réutilises.

---

Pas d'accord.

un bon vieux
while(){
Obj obj = new Obj();
...
}

c'est le reve, c'est lisible propre etc...
Et en plus la JVM va optimiser ca d'elle meme bien mieux que de sortir la variable de la boucle.
L'optimisation de l'execution en Java consiste uniquement (presque) a bien penser sont code.

tu fais bien de dire qu'il faut bien penser son code.

Java n'optimise pas du tout la gestion de la mémoire, il épargne juste à l'utilisateur d'y penser.

Faire une alloc infinie d'un nouvel espace mémoire a chaque fois, pour un peu que ça aille vite et que ça prenne de la place, ça peut faire sauter le programme, tant en utilisation mémoire qu'en cpu.

En plus, prendre ce genre de tres mauvaises habitudes empeche tout passage a un autre langage..

Enfin, déclarer les variables partout dans le code, en terme de lisibilité, c'est pas le must.

Après, c'est une question d'école de pensée, si on compte faire du java toute sa vie, et qu'on maitrise le gc, alors on fait comme on veut.

Citation:

---

Envoyé par BainE

Pas d'accord.

un bon vieux
while(){
Obj obj = new Obj();
...
}

c'est le reve, c'est lisible propre etc...
Et en plus la JVM va optimiser ca d'elle meme bien mieux que de sortir la variable de la boucle.
L'optimisation de l'execution en Java consiste uniquement (presque) a bien penser sont code.

---

Je peux pas laisser dire ça.
Quand tu travailles sur de gros projets où la performance est importante, tu DOIS optimiser certaines choses.

Petit exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

public class Test { public int propriete1;   public Test() { }   public void setPropriete1(int prop) { propriete1 = prop; }   public Test(int prop){ propriete1 = prop; }   public static void main(String[] args) { //un random histoire d'avoir des valeurs a setter Random r = new Random();   //--------Test 1--------------- long time = System.currentTimeMillis(); for (int i=0;i<100000000;i++){ Test t = new Test(r.nextInt()); } time -= System.currentTimeMillis(); System.out.println(time);   //--------Test 2----------------- long time2 = System.currentTimeMillis(); Test t2 = new Test(); for (int i=0;i<100000000;i++){ t2.setPropriete1(r.nextInt()); } time2 -= System.currentTimeMillis(); System.out.println(time2); } }

---

Et voici la sortie :

Code:

---

1 2	-5704 -1907

---

Le résultat parle de lui même.
Quand on doit faire d'énormes traitements, il faut optimiser un minimum. La JVM ne remplacera jamais l'optimisation humaine.

La création d'objet est une des choses les plus lourdes en java. Il faut au maximum la sortir des boucles (quand on peut bien sûr, après c'est un compromis entre lisibilité et performance)

J'ai dit une enormité...
Et bé j'ai du boulot a reprendre...
Et sun pourrait faire un effort, je suis plus sur de rien mais il me semble que mes vieux compilo C font ce genre d'optimisation depuis un bail

Citation:

---

Envoyé par BainE

Pas d'accord.

un bon vieux
while(){
Obj obj = new Obj();
...
}

c'est le reve, c'est lisible propre etc...

---

Tu as confondu cet exemple et:

Code:

---

1 2 3 4

Object o; while(condition) { o = new Object(); }

---

Là ça ne change rien niveau performances, c'est juste que la poignée vers l'objet o est définie une fois pour toute, et ça c'est optimisé par le compilo... Mais pas le new :)

ouaip c'est exactement ca, ca viens d'une discution (ecoute surtout pour moi) avec adiGuba et je me suis un peu emballé.

Par contre va falloir que je test ce que ca donne en C ce soir, ca m'intrigue :P

Ne pas oublier non-plus que les specs sont assez larges (trop meme) et que chaque vendeur puisse faire des optimisations de gestion de memoire, du GC, du compilateur, etc... a sa sauce. L'une des raisons pour lesquelles la VM de Microsoft (avant LE proces...) etait plus "rapide" venait aussi d'une politique de GC plus aggressive (apres il avaient aussi bidouille des trucs "interdits"...).

Egalement le compilateur des JDK 1.2/1.3 d'IBM tendait a faire de meilleures optimisations que celui de Sun. Et les VM d'IBM avaient aussi un GC different.

Donc, ne jamais compter sur l'optimisation de la jvm, à moins de savoir sur laquelle le prog va tourner.

Salut,

Citation:

---

Envoyé par bouye

L'une des raisons pour lesquelles la VM de Microsoft (avant LE proces...) etait plus "rapide" venait aussi d'une politique de GC plus aggressive (apres il avaient aussi bidouille des trucs "interdits"...).

---

Il me semble que la VM de Microsoft était également la première à utiliser un compilateur JIT...

Citation:

---

Envoyé par Satch

Donc, ne jamais compter sur l'optimisation de la jvm, à moins de savoir sur laquelle le prog va tourner.

---

Pour moi il faut avant tout se focaliser sur la lisibilité du code source, et éviter de l'optimiser à tout va...

L'optimisation ne doit venir qu'après avoir détecté l'origine du problème de performance, et non pas avant.


Enfin, en Java, et mis à part quelques cas particuliers, l'optimisation se fait plus sur les algorythmes que sur des "bidouilles" de code... car quelque soit l'implémentation du compilateur/JVM il y a de forte chance qu'il s'en sorte mieux ;)

a++

Les SoftValue chez IBM c'est pas mal non plus! Véridique....:oops:

Citation:

---

Envoyé par adiGuba

L'optimisation ne doit venir qu'après avoir détecté l'origine du problème de performance, et non pas avant.

---

Y a quand même quelques réflexes "de base" à avoir, surtout dans le cas de grosses appli.
Par exemple, utiliser le Stringbuffer quand on a pas mal de String à concaténer.
Ou encore éviter d'utiliser l'autoboxing dans une boucle avec énormément d'itérations.