[Optimisation][Infos] Détails techniques

Bonjour,

je travaille actuellement au Vietnam dans une boite de développement Offshore.

Dans mon projet actuel, on bosse sur des projets J2EE. Avec ma petite équipe, je suis souvent confronté à des lignes de programmation comme celles-ci:

Code:

---

1 2 3 4 5 6 7 8

for(in i = 0; i < maListe.size(); i++) { MaClasse monObjet = (MaClasse) maListe.get(i); String attribut1 = monObjet.getAttribut1(); ... if (<un certaine condition de sortie>) return; }

---

De quoi je me plaints : Déclaration de variable dans une boucle, return brutal. En cours d'algo, on nous a tellement martelé le cerveau sur les notions d'invariants de boucle et tout le toutim qui va avec. Et quand je vois ce genre de code, j'ai des sueurs froides

Ils me disent que ça tourne/ça marche. Moi je leur dis qu'au niveau algorithmique c'est quand même pas terrible. En fait, je poste un message pour demander aux experts des details techniques concernant l'exécution du code ci-dessous par la JVM. Pourquoi il n'est pas top. Ca me permettra de renforcer mon argumentation.

Merci

Bonjour,

Pour ma part, je ne vois aucun problème de déclarer des variables dans une boucle. Je dirai que c'est une bonne pratique vu que ces variables sont déclarées et visibles que dans le bloc où elles sont utilisées.

Et toi, comment aurais-tu codé cette boucle?

Absolument aucun pb dans ce code.

Ok, chippotons, je préfère mettre des acolades après un if et j'utiliserai la nouvelle boucle if de Java 5.0 (pas encore dispo dans la JEE).
:lol:

Outre les limitations techniques à certains languages (qui obligent par exemple à tout déclarer au début ou qui ne peuvent pas avoir de blocs dépassant une certaine taille ou dont les noms de variables sont limités à 5 lettres max), certains styles de prog sont (TRES - voir guerres de religions) fortement dépendants du lycéee/la fac/le livre/le site web, bref l'endroit où tu as appris à programmer, de qui t'as formé et/ou de l'endroit où tu bosses. Sans compter que le compilateur peut repasser derrère et optimiser tout ca sans que tu le sache.

La prog ca change et évolue avec le temps. Hum en fin de DESS les profs nous avaient fait marrer en nous listant les règles de programmation auquelles ils avaient eux eût droit au début des années 80... top marrant...

Sinon lire les bouqins sur Java et voir le site de Sun pour les recommendations de programmation en ce language.

Note perso : mais ouf quel plaisir en passant du C et du Pascal à C++ et à Java en envoyant tout ce genre de contraintes valser à la poubelle... Et en plus au final c'est bien plus lisible !

Citation:

---

Envoyé par sleepy2002

Bonjour,

je travaille actuellement au Vietnam dans une boite de développement Offshore.

Dans mon projet actuel, on bosse sur des projets J2EE. Avec ma petite équipe, je suis souvent confronté à des lignes de programmation comme celles-ci:

Code:

---

1 2 3 4 5 6 7 8

for(in i = 0; i < maListe.size(); i++) { MaClasse monObjet = (MaClasse) maListe.get(i); String attribut1 = monObjet.getAttribut1(); ... if (<un certaine condition de sortie>) return; }

---

De quoi je me plaints : Déclaration de variable dans une boucle, return brutal. En cours d'algo, on nous a tellement martelé le cerveau sur les notions d'invariants de boucle et tout le toutim qui va avec. Et quand je vois ce genre de code, j'ai des sueurs froides

Ils me disent que ça tourne/ça marche. Moi je leur dis qu'au niveau algorithmique c'est quand même pas terrible. En fait, je poste un message pour demander aux experts des details techniques concernant l'exécution du code ci-dessous par la JVM. Pourquoi il n'est pas top. Ca me permettra de renforcer mon argumentation.

Merci

---

Pour moi non plus, aucun probleme, les variables déclarées sont des références en plus de ça => aucun soucis a te faire au niveau des perf...

apres pour l utilisation des return, break, continue a chacun de voir :wink:

C'est vrai qu'un return brutal comme ca marche parfaitement mais c'est souvient mieux de faire un while (ou do while) avec un bon gardien de boucle.

Pour ce qui est des déclarations de variables dans la boucle, je pense que ca ne pose aucun problème vu que le compilateur arrangera tout ça pour lui.

Je ne vois aucun probleme dans ce type de code. Le fait de ne pas mettre de return "brutal" comme tu dis vient du langage procedural et pour moi ca ne pose aucun probleme dans la pratique.
Pour la declaration de variable, il est parfois obligatoire de le faire dans la boucle

Code:

---

1 2 3 4

for (int i=0;i<liste.size();i++) { Object obj = (Object)liste.get(i); //manipulation de l'objet qui oblige d'avoir une adresse differente de l'iteration precedente }

---

Pour ce qui est des accolades, à mon avis, ca aussi ca vient d'une habitude dans d'autres langages. En java, ça ne pose pas de probleme.

Pour mettre mon grain de sel:

La declaration dans la boucle est pas super sexy mais si ca se trouve le compilo la vire de la boucle pour optimizer de toute facon, si qqun a le courage de verifier.

Declarer une var dans une boucle c'est mal! Pourquoi ?

A chaque declaration d'une variable dans un bloc (typiquement le bloc de la boucle), la VM alloue la place pour la variable sur la pile. Avouez qu'on a tout de meme vu mieux au niveau optimization des ressources non ?

Par contre au niveau performances si c'est une grosse boucle ce serait bien aussi de faire:

Code:

---

1 2	int taille = maListe.size(); for (int i = 0; i < taille; i++)

---

Tant qu'on en est a chipoter, appeler un increment de boucle i meme si c'est tres repandu, c'est pas top. Pourquoi ? En cas de probleme une recherche sur i sera bcp moins efficace qu'une recherche sur index par exemple.. sans compter qu'en cas de boucles imbriquees, i, j, k, l ... bonjour la relecture avec un nom clair moins de risque de confusions.

Bulbo :wink:

Citation:

---

Envoyé par bulbo

Declarer une var dans une boucle c'est mal! Pourquoi ?

A chaque declaration d'une variable dans un bloc (typiquement le bloc de la boucle), la VM alloue la place pour la variable sur la pile. Avouez qu'on a tout de meme vu mieux au niveau optimization des ressources non ?

---

:?: :?: :?:

Peux-tu expliquer?

Dans l'exemple donné par sleepy2002, la VM alloue seulement une place dans la pile (stack) pour conserver la référence sur monObjet et non à chaque itération comme tu l'écris.

Citation:

---

Envoyé par jowo

Bonjour,

Pour ma part, je ne vois aucun problème de déclarer des variables dans une boucle. Je dirai que c'est une bonne pratique vu que ces variables sont déclarées et visibles que dans le bloc où elles sont utilisées.

Et toi, comment aurais-tu codé cette boucle?

---

Ben en fait je l'aurai fait de cette manière :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

MaClasse monObjet = null; String attribut1 = null; int i = 0; boolean pasDePb = true; while (i < maListe.size() && pasDePb) { monObjet = (MaClasse) maListe.get(i); attribut1 = monObjet.getAttribut1(); ... if (<condition de sortie> pasDePb = false;   i++; }

---

Vu qu'à chaque itération on n'utilise qu'un essemble unique de variables, je me disais qu'il était logique de les déclarer avant la boucle. Effectivement dans les cas où l'on a des boucles imriquées et que des variables ne sont utilisées que pour des cas précis dans la/les boucles, c'est pas mal de les déclarer au moment où l'on en a besoin.

Sinon merci pour vos détails technique, j'essaye d'avoir l'avis d'expert comme ça je peux réviser mon jugement :P.

Citation:

---

Envoyé par jowo

Dans l'exemple donné par sleepy2002, la VM alloue seulement une place dans la pile (stack) pour conserver la référence sur monObjet et non à chaque itération comme tu l'écris.

---

Au temps pour moi, je suis creve ce matin .. je devrais eviter les discussions techniques :oops:

Mais bon ca reste une bonne habitude de declarer tout ce que l'on peut avant une boucle ..

Par contre ce que j'ai dit est valable dans le cas de boucles imbriquees .. je me rattrape comme je peux :wink:

Bulbo :oops:

Oui MAIS justement comme il a été dit plus haut et ce grace aux divers optimisations des compilateurs modernes (pas que Java, ca marche aussi dans C++ et les autre languages également) tu n'as pas besoin (en général) de faire ce genre d'optimisations toi-même : le compilateur s'en charge pour toi.

Ok, ok ici c'était un exemple simple mais faire trop de choses de genre peut nuire à la lisibilité du code (et donc à ca réutilisation ou à sa maintenance par qqun d'autre). Qui plus est certaines optimisation personelles ont actuellement des effets contraires à ceux espérés soit directement dans le code (utilisation de la mauvaise variable à la mauvaise valeur), soit justement à cause des optimisations apportées ultérieurement par le compilateur.

Il y a 10~20 ans le moto c'était (entre autre) : réutilisez des variables pour éviter de gaspiller la mémoire.
Aujourd'hui le moto c'est : faîtes quelque chose de sécurisé* et de lisible et par pitié laissez le compilateur faire son boulot d'optimisations. Limitez la visibilité (les variables ne sortent pas des blocs) et surtout ne faîtes pas d'optimisations** de bouts de chandelles !

*en évitant de réutiliser les même variables pour des traitement différents ce qui peut ammener des erreur ou des pb.

** Sauf si vous vous appelez John Carmack et/ou que vous programmez en assembleur.

Bon évidement ca ne veux pas dire non-plus qu'il faut pour autant programmer comme un saguoin.

Edit - Hum faudrait'il faire a nouveau comme en C et définir toutes nos variables de parcours d'index bien gentiment tout en haut de notre méthode ? Egalement empiler des appels de methodes atomiques ca bouffe une mémoire monstreuses, revenons au code mono-bloc !

Salut,


Je suis en gros du même avis que bouye, mais il est toujours utile de connaitre le fonctionnement du compilateur et des ses optimisations/remplacements afin d'éviter certaines surprises...

L'exemple le plus frappant est l'utilisation de l'opérateur + entre deux String dans une boucle qui provoque de nombreuse allocation/desallocation inutile...

a++

Citation:

---

l'opérateur + entre deux String

---

Exact ca c'est quelque chose de tres important et ni la doc ni les livres n'insistent réellement dessus.

On peut ajouter aussi que parcourir une liste en ayant recours aux get(index) peut être très pénalisant.
A ne faire que si l'on est sûr s'agit d'une ArrayList.
Personnellement, j'aurais écrit la boucle comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Iterator it = maListe.iterator(); MaClasse monObjet = null; boolean ok = true; while(it.hasNext() && ok) { monObjet = (MaClasse) maListe.next(); String attribut1 = monObjet.getAttribut1(); ... if (<un certaine condition de sortie>) ok = false; }

---

Citation:

---

Envoyé par bouye

Citation:

---

l'opérateur + entre deux String

---

Exact ca c'est quelque chose de tres important et ni la doc ni les livres n'insistent réellement dessus.

---

Très interessant comme point. Donc dans ce genre de cas, il faut utiliser un StringBuffer ?

Avant Java 5.0 => StringBuffer
Depuis Java 5.0 => StringBuilder (sauf si on a besoin d'une synchronisation a ce moment-là on peut utiliser StringBuffer).

Voir la FAQ.

Citation:

---

Envoyé par NGY

On peut ajouter aussi que parcourir une liste en ayant recours aux get(index) peut être très pénalisant.
A ne faire que si l'on est sûr s'agit d'une ArrayList.

---

En effet sur une grosse LinkedList cela peut être assez pénalisant... mais même sur une ArrayList cela n'est pas super "propre" comme traitement (en particulier si on supprime des éléments de la liste)... Il est preferable de toujours utiliser l'itérateur (et encore plus avec Java 5.0 et le for étendu).

Citation:

---

Envoyé par sleepy2002

Très interessant comme point. Donc dans ce genre de cas, il faut utiliser un StringBuffer ?

---

Oui car sinon le compilateur utilisera un StringBuffer pour chaque itération de la boucle... Cf la FAQ : Comment concatener des chaînes de caractères ?.

a++

Le seul truc ki me gène dans ce code c de déclarer et de recréer a chaque fois la variable.... c pas top niveau mémoire. Mais vu les capacité des mémoires maintenant. C sur ke nous aussi les profs d'algo nous ont cassé les pieds avec ça. mais je suis d'accord c aps très joli comme sode.

Citation : Effective Java Programming Language Guide, Joshua Bloch, The Java Series - Addision Wesley ISBN 0-201-31005-8

Note : j'ai mis en gras ce qui est en gras dans le bouquin.

Page 141

Citation:

---

Item 29: Minimize the scope of local variables

This item is similar in nature to Item 12, "Minimize the accessibility of classes and members." By minimizing the scope of local variables, you increase the readability and maintainability of your code and reduce the likelihood of error.
The C programming language mandates that local variables must be declared at the head of the block, and programmers continue to do this out of habit; it's a habit worth breaking. As a reminder, the Java programming language lets you declare variables anywhere a statement is legal.
The most powerful technique for minimizing the scope of a local variable is to declare it where it is first used.
( ... )

---

Le reste de l'item indique pourquoi les boucles for sont préférables aux boucles while.

Page162

Citation:

---

Item 37: Optimize judiciously

There are three aphorisms concerning otptimization that everyone should know. They are perhaps beginning to suffer from overexposure, but in a case you aren't yet familiar with them, here they are:

- More computing sins are commited in the name of efficiency (without necessarly achieving it) that for any other single reason - including blind stupidity.
- Wiliam A. Wulf (A case Agains the GOTO, Proceedings of the 25th ACM NAtional Conference 2 (1972))

- We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
- Donald E. Knuth (Structured Programming with go to Statements, Computing Survey 6 (1974)).

- We follow two rules in the matter of optimization :
Rule 1. Don't do it.
Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.
- M. A. Jackson (Principles of Program Design, Academic Press (1975))

All of there aphorisms predate the Java programming language by two decades. They tell a deep truth about optimization: it's easy to do more harm than good, especially if you optimize prematurely. In the process, you may produce software that is neither fast nor correct an cannot easily be fixed.
Don't sacrifice sound architectural principles for performance. Strive to write good programs rather than fast ones.
( ... )

---

En gros
1) soyez vraiment sur que le programme marche bien avant d'optimiser.
2) n'optimisez pas quand ce n'est pas nécessaire*.
3) essayez d'optimizer l'architecture plutot que le code.

*Systeme temps réel/critiques/embarqués = oui mieux vaut faire des optimisations après vérification que le programme marche.
postes clients = êtes-vous vraiment sûrs que le jeu en vaut la chandelle ?

Bonjour,

pour moi déclarer des variables dans une boucle est, sauf justifications, définitivement une horreur que le compilateur ne peut pas optimiser.

Comme indiquer dans ce thread, il existe des cas ou il est nécessaire de le faire (ces variables sont utilisée par ailleurs). Je ne vois pas comment le compilateur pourrait savoir quand déporter et quand ne pas le faire.

Il ne faut pas oublier que souvent gain de mémoire = gain de performance (moins de passage du gc) même avec des serveurs à 1 Go de RAM.

Par contre il est inutile d'utiliser des stringBuffer si on a le code suivant

Code:

---

1 2	chaine = "debut de la phrase " +"fin de la phrase";

---

ça le compilateur sait le faire tout seul.

un site de best practice J2EE :

http://www.javapractices.com/index.cjp


Je suis d'accord toutes les applications ne mérite pas une campagne de profiling mais il est des modifications qui ne coute rien (déclarer les variables en dehors de la boucle n'est pas plus difficile que de le faire à l'intérieur).

return dans la boucle for.
Effectivement c'est pas beau mais si le client l'accepte (de plus en plus font des revues de code et impose des conventions de codage)

NGY : tu ne peux pas être derrière chaque developpeur et je te conseille l'utilisation d'outils comme checkstyle ou findbugs

Pour remettre mon grain de sel .. declarer une variable en dehors ou dans une boucle n'influe pas sur le GC, la variable va dans tout les cas sur la pile et l'objet cree ira dans le tas.

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..
Attention j'ai pas dit que c'etait joli a relire, je dis juste que ca peut etre evite.

Bulbo :wink:

Citation:

---

Envoyé par Pietra

pour moi déclarer des variables dans une boucle est, sauf justifications, définitivement une horreur que le compilateur ne peut pas optimiser.

---

Pour moi c'est le contraire : cela ne sert à rien de déclarer une variable en dehors d'une boucle si elle ne doit être utilisé que dans la boucle... (sauf si l'objet restera identique pour toute la boucle, dans ce cas cela évite de le réallouer à chaque fois).

Citation:

---

Envoyé par Pietra

Je ne vois pas comment le compilateur pourrait savoir quand déporter et quand ne pas le faire.

---

Il me semble que le compilateur ne déporte pas la variable, mais conserve sa référence pour l'itération suivante... donc il ne devrait pas y avoir de différence à l'exécution... [en prévisualisant je viens de voir la remarque de bulbo qui me confirme cela]
De plus cela permet au garbage collector de libérer l'objet au plus tot à la fin de la boucle.

Citation:

---

Envoyé par Pietra

Il ne faut pas oublier que souvent gain de mémoire = gain de performance (moins de passage du gc) même avec des serveurs à 1 Go de RAM.

---

Oui mais que tu fasses :

Code:

---

1 2 3 4

Object o; for ( ... ) { o = new Object(); }

---

ou

Code:

---

1 2 3

for ( ... ) { Object o = new Object(); }

---

Il y a autant d'objets créés...

Citation:

---

Envoyé par Pietra

Par contre il est inutile d'utiliser des stringBuffer si on a le code suivant

Code:

---

1 2	chaine = "debut de la phrase " +"fin de la phrase";

---

ça le compilateur sait le faire tout seul.

---

En effet mais personne n'a dit le contraire. La remarque concernait les boucles du style :

Code:

---

1 2 3 4

String s = ""; for (...) { s += ...; }

---

Citation:

---

Envoyé par bulbo

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..

---

Rien ne t'oblige à la déclarer en dehors de la boucle...

Citation:

---

Envoyé par Pietra

pour moi déclarer des variables dans une boucle est, sauf justifications, définitivement une horreur que le compilateur ne peut pas optimiser.

---

D'où as-tu lu cette information? As-tu un lien sur ce sujet? Je veux bien te croire mais il me faut des preuves.

Pour moi, déclarer une variable dans une boucle c'est une excellente pratique :wink: . Car dans ce cas, le compilateur sait que cette variable sera utilisée que dans ce bloc. À mon avis, il pourrait donc mieux optimiser son utilisation dans la boucle.

Avec ma philosophie, on pourrait aller jusqu'à l'extrême et déclarer des blocs dans les méthodes.

Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public int XXX(int a) { int x;   { int b; int c;   /* traitement de a à l'aide de b e*/ }   { int d; int e;   /* calcul de x en fonction de a à l'aide de d et e*/ }   return x; }

---

Je reconnais que dans ce cas le code devient illisible et dans la pratique je ne programme pas de cette manière :wink: .

Je ne suis pas un spécialiste et j'attends avec impatience vos réactions.

Citation:

---

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..

---

non, j'ai eu le cas récemment je parcours un gros fichier servant à initialiser des objets (n lignes de propriétés par objet).
avec une déclaration à l'exterieur tous mes objets avaient exactement les mêmes valeurs (celles du dernier objet du fichier).

Si tu declare ta variable en dehors de la boucle alors tu modifie seulement la valeur dans ta boucle. tu garde la même référence pour toutes tes variables.

Si tu la déclare dans la boucle alors c'est comme si tu avait autant de variable que d'itérations.
Conclusion : le nombre d'objet crées est différent

Donc pour moi c'est confirmé par l'expérience :
déclarer des objets dans une boucle alors que cela n'est pas nécessaire est une abbération


NB : la mémoire est libérée lorsque le garbage collector passe et celui ci se déclenche uniquement lorsque la mémoire disponible est insuffisante.
une variable déclarée avec une protée plus faible est simplement éligible plus tôt pour le gc.
Cette optimisation est donc moins visible que d'autres.

Dans le cas de boucles imbriquees cela change tout:

Code:

---

1 2 3 4 5 6 7

for (int index1 = 0; index1 < 10; index1++) { for (int index2 = 0; index2 < 10; index2++) { Object obj = ... } }

---

La on va empiler dix fois la variable obj alors que si elle avait ete declaree a l'exterieure de la boucle on ne l'aurait empilee qu'une fois..
C'est probablement aussi le cas d'index2 d'ailleurs..

Bulbo :wink:

Citation:

---

Envoyé par Pietra

Citation:

---

Maintenant j'aimerais un exemple qui me prouve qu'une variable doit etre obligatoirement declaree dans une boucle .. pour moi ca peut toujours etre a l'exterieur ..

---

non, j'ai eu le cas récemment je parcours un gros fichier servant à initialiser des objets (n lignes de propriétés par objet).
avec une déclaration à l'exterieur tous mes objets avaient exactement les mêmes valeurs (celles du dernier objet du fichier).

Si tu declare ta variable en dehors de la boucle alors tu modifie seulement la valeur dans ta boucle. tu garde la même référence pour toutes tes variables.

Si tu la déclare dans la boucle alors c'est comme si tu avait autant de variable que d'itérations.
Conclusion : le nombre d'objet crées est différent

Donc pour moi c'est confirmé par l'expérience :
déclarer des objets dans une boucle alors que cela n'est pas nécessaire est une abbération


NB : la mémoire est libérée lorsque le garbage collector passe et celui ci se déclenche uniquement lorsque la mémoire disponible est insuffisante.
une variable déclarée avec une protée plus faible est simplement éligible plus tôt pour le gc.
Cette optimisation est donc moins visible que d'autres.

---

Hum te vexe pas mais c'est du n'importe quoi .. ou du moins c'est ce qu'il me semble .. tu pourrais mettre un bout de code pour illustrer ton propos ?

Genre une boucle qui alloue plus d'objet si la declaration est dans la boucle au lieu d'etre a l'exterieure ..

Bulbo :wink:

Citation:

---

Envoyé par bulbo

Dans le cas de boucles imbriquees cela change tout:

Code:

---

1 2 3 4 5 6 7

for (int index1 = 0; index1 < 10; index1++) { for (int index2 = 0; index2 < 10; index2++) { Object obj = ... } }

---

La on va empiler dix fois la variable obj alors que si elle avait ete declaree a l'exterieure de la boucle on ne l'aurait empilee qu'une fois..
C'est probablement aussi le cas d'index2 d'ailleurs..

Bulbo :wink:

---

Attention, il ne faut pas confondre imbrication et empilement. La variable "obj", locale à la seconde boucle, a la portée de cette boucle, i.e. elle n'est pas CONNUE (et donc inaccessible) en dehors de celle-ci.
Donc, le compilateur, suffisamment intelligent, sait qu'il peut réutiliser le MEME emplacement mémoire dans la pile pour y stocker la valeur de cette variable. D'ailleurs cet emplacement peut être très bien réutilisée, lorsqu'on sort de la boucle, pour y stocker une autre variable qui serait déclarée à la suite.
En conclusion, une seule et unique zone mémoire est nécessaire dans la pile pour stocker la référence "obj".

Autre point à éclaircir.... Un empilement de données (sous-entendu dans la pile) a lieu uniquement lors de l'appel d'une méthode.... Rien à voir avec l'imbrication de boucles... J'espère que c'est clair :wink:

Citation:

---

Envoyé par Pietra

NB : la mémoire est libérée lorsque le garbage collector passe et celui ci se déclenche uniquement lorsque la mémoire disponible est insuffisante.
une variable déclarée avec une protée plus faible est simplement éligible plus tôt pour le gc.
Cette optimisation est donc moins visible que d'autres.

---

Non, le GC se déclenche quand bon lui semble, et pas uniquement lorsque la mémoire disponible est insuffisante, sinon les performances de l'appli seraient catastrophiques !! Rappelons que le GC est un thread de basse priorité.
L'élection d'une variable par le GC n'a rien à voir avec sa portée. Il faut distinguer les variables de type primitifs, qui elles sont allouées en pile, que le GC ne connaît pas du tout, des objets qui eux sont créés dans le tas et dont la durée de vie n'a rien à voir avec leur portée.

Code:

---

1 2 3 4

Object getObject() { Object o = new Object(); retrun o; }

---

La portée de "o" est la méthode getObject(), maintenant quant à sa durée de vie.......