Je me demandais comment le collecteur des ordures de Java traite de la situation suivante.
objet A a une référence à l'objet B et à l'objet B a une référence à l'objet C. Le programme principal a une référence à l'objet A. Vous pouvez donc utiliser l'objet d'objet B de l'objet B, ainsi que l'objet de l'objet auge B.
Qu'est-ce qui arrive à l'objet B et à l'objet C, si le lien entre objet A et objet B est défini sur NULL?
Si l'objet B et l'objet C sont maintenant collectés par le collecteur des ordures? Je veux dire qu'il existe toujours une connexion entre objet b et objet c.
9 Réponses :
Vous ne pouvez pas compter sur le collecteur des ordures pour travailler à une heure précise, car son comportement est imprévisible, tout ce que vous pouvez dire est que les objets B et C ne sont éligibles que pour la collecte des ordures
Je pense que la logique est différente. Si l'objet n'est pas accessible à partir d'un thread, il peut être collecté.
Oui, B et C sont éligibles pour la collecte des ordures, s'ils ne peuvent pas être atteints à partir d'une racine de GC (les racines GC sont généralement toutes les filets et toutes les références sur la pile).
@MAURICE: Pas directement, autant que je sache. Les variables statiques sont accessibles via la classe Ils appartiennent à, qui peuvent être atteintes via le chargeur de classes qui les chargaient, qui peuvent être atteints via d'autres classes qu'elle est chargée qui peut être chargée. atteint par des objets de ce type. Donc, si le chargeur de classes est flanc, vous pouvez même perdre la valeur d'une variable statique.
@ JOOCHIM: Les variables statiques ne font pas partie d'une classe et non d'un objet?
@ JOOCHIM: Voir Sujet du sujet, j'ai ajouté une question supplémentaire.
devrait objet b et objet c maintenant été recueillies par le collecteur des ordures?
Oui. Eh bien, ils sont candidats à la collecte car il n'ya aucun moyen d'atteindre l'objet B et C à travers la racine qui est une.
S'il n'y a pas de référence à l'objet, il conviendra alors au GC pour continuer
En fait, la collecte des ordures à Java est une chose très sophistiquée, bien plus que dans l'interprète Ruby, à titre d'exemple.
Quoi qu'il en soit, la base théorique est la même.
Le GC identifie les graphiques d'objets qui ne sont plus accessibles par code de programme (c'est-à-dire qu'ils n'ont plus de référence en code actif). Lorsque vous parlez de graphique d'objet, je parle avec précision de B-> C Objet graphique. Une fois qu'il est inaccessible, cela peut être GC'ed, mais vous ne pouvez pas dire quand ce sera, en raison de la GC, essayant d'optimiser autant que possible, son travail pour éviter de ralentir l'application.
B et C sont éligibles pour la collecte des ordures, car vous ne pouvez plus y accéder. Avec l'imprégnation du collecteur des ordures Tout ce que nous savons, c'est qu'ils sont très susceptibles d'être collectés à un moment donné à l'avenir.
B n'a aucune référence à celui-ci, il sera donc déposé en premier, il comprendra que C n'a aucune référence, donc C sera des ordures collectées. C'est pour l'illustration, JVM est assez intelligent pour les ramasser dans un balayage.
Il n'ya aucun moyen de dire que B sera GC'ed en premier, c'est-à-dire que vous ne devriez pas avoir de code de finaliseur en B et C qui dépend de cet ordre. Le GC ne compte pas les références, mais vérifie l'accessibilité. Si les deux B et C ne peuvent pas être atteints, ils sont également inaccessibles.
Comme d'habitude, ce Article est un Doit-lire pour quiconque veut comprendre quelle collecte de déchets fait. Il est bien écrit et a des dessins explicatifs.
En ouvrant le lien, j'ai besoin d'un nom d'utilisateur et d'un mot de passe.
Ah, FTP frappe à nouveau. J'ai édité mon message, avec un autre lien qui devrait fonctionner mieux. Il y a aussi une version PDF.
@ Bright010957: Tada! ritdml.rit.edu/dspace/bitstream/1850/5112/ 1 / ...
J'ai posé l'autre question dans un autre post: Stackoverflow.com/Questtions/2433261/...