Admissibilité de la collecte des ordures

Question

Ce code est une partie de mon test de classe -

class Bar { } 
class Test 
{ 
    Bar doBar() 
    { 
     Bar b = new Bar(); /* Line 6 */ 
     return b; /* Line 7 */ 
    } 
    public static void main (String args[]) 
    { 
     Test t = new Test(); /* Line 11 */ 
     Bar newBar = t.doBar(); /* Line 12 */ 
     System.out.println("newBar"); 
     newBar = new Bar(); /* Line 14 */ 
     System.out.println("finishing"); /* Line 15 */ 
    } 
} 

A quel point est l'objet Bar, créé le line 6, admissible à la collecte des ordures? Est-ce lorsque doBar() est terminé?

Answer 1

Toutes les références à l'objet Bar créé sur la ligne 6 sont détruits quand une nouvelle référence à un nouvel objet Bar est affecté à la newBar variable sur la ligne 14. Par conséquent l'objet Bar, créé sur la ligne 6, est admissible à la collecte des ordures après la ligne 14.

Il est pas quand doBar() termine parce que la référence dans la méthode doBar() est retourné sur la ligne 7 et est stockée dans newBar la ligne 12. Ce preserver l'objet créé sur la ligne 6.

Answer 2

après l'affectation à lin 14 est exécutée. À ce stade, il n'y a plus aucune référence à Bar objet de la ligne 6 existe plus.

Answer 3

Je suis d'accord avec jiltedpotato (Ce serait après la ligne 14). Un objet est éligible pour la récupération de place, lorsque toutes les références à celui-ci sont perdues ou ignorées.

Jetez un oeil à: When Is The Object Eligible For Garbage Collection?

Answer 4

Aussi simple que lorsqu'il n'y a pas de référence à un objet sera admissible à la collecte des ordures, mais quand sera-t exactement collecté dépend de GC algo.

Answer 5

Des questions de ce genre semblent être très populaires lors de l'enseignement de Java aux débutants, mais sont complètement absurdes. Alors qu'un answer like this est génial pour faire, celui qui a inventé cette question, heureux, ce n'est pas correct quand creuser plus profond:

Les références aux objets contenus dans les variables locales n'empêchent pas les objets d'être collectés. Si le code suivant ne les touche pas, ces objets peuvent toujours être considérés comme inaccessibles, ce qui n'est pas un problème théorique. Comme démontré dans “finalize() called on strongly reachable object in Java 8”, même l'exécution en cours d'une méthode de cet objet n'entrave pas sa collecte, si l'instance n'est pas touchée par la suite. Comme dans votre exemple de code, les objets ne contiennent aucune donnée, il est évident qu'ils ne sont jamais touchés, ce qui implique qu'ils peuvent être collectés à tout moment, en fonction de l'état d'optimisation de la JVM. Le code peut également être optimisé à un degré tel qu'il n'effectue que l'effet secondaire visible des deux instructions d'impression, c'est-à-dire que les objets ne sont jamais créés du tout.

Ceci est soutenu par The Java® Language Specification, § 12.6.1. Implementing Finalization:

transformations Optimisation d'un programme peut être conçu pour réduire le nombre d'objets qui sont accessibles à moins de celles qui seraient considérés comme accessibles naïvement être. Par exemple, un compilateur Java ou un générateur de code peut choisir de définir une variable ou un paramètre qui ne sera plus utilisé pour null pour que le stockage d'un tel objet soit potentiellement récupérable plus tôt.

Un autre exemple de ceci se produit si les valeurs dans les champs d'un objet sont stockées dans des registres. Le programme peut alors accéder aux registres à la place de l'objet et ne plus jamais accéder à l'objet. Cela impliquerait que l'objet est garbage....

Pratiquement, puisque c'est trivial code court-courant à l'intérieur d'une méthode main, le scénario le plus courant serait que le code fonctionne unoptimized, mais pas de collecte des ordures ne se fera jamais dans ce court laps de temps d'exécution.

---

Ceci conduit à l'autre raison pour laquelle poser de telles questions n'a aucun sens. Il peut être difficile de trouver les bons points quand un objet est naïvement considéré comme inaccessible, il sera impossible de deviner quand et comment l'optimiseur influence le résultat, mais le but entier de la collecte des ordures est que le développeur n'a pas à s'inquiéter à ce sujet.