Dans le livre C # 5.0 en un mot de Joseph Albahari J'ai trouvé ce p>
Là où il est dit dès que vous passez la ligne de code où une variable est utilisée lors de la dernière utilisation, l'objet référencé par elle est éligible à la collecte des ordures (c'est-à-dire si aucune autre variable ne contient une référence à cet objet). p>
Cependant, selon Cette conférence de UC Berkley, tant que la référence à la L'objet existe sur la pile, il ne sera pas rassemblé. Ma compréhension est que la méthode revienne, la variable reste sur la pile. Ce qui signifie que tout objet référencé par elle est vivant jusqu'à ce que la méthode revienne. p>
est-ce une erreur dans le livre ou la collecte de poubages Java et .NET. P>
4 Réponses :
Le livre est correct. P>
in .NET, le collecteur des ordures contient des informations sur l'endroit où la variable est utilisée et dès qu'elle est inutilisée, l'objet est éligible pour la collecte des ordures. P>
(Toutefois, si vous exécutez le code avec un débogueur attaché, le collecteur des ordures change de comportement. Il conserve l'objet pour l'ensemble de la variable, non seulement lorsque la variable est utilisée, de sorte que l'objet puisse être étudié dans le débogueur.) p>
Ma compréhension est, jusqu'à ce que la méthode revienne, la variable reste sur la pile. Ce qui signifie que tout objet référencé par elle est vivant jusqu'à ce que la méthode revienne. P> blockQuote>
Le JIT est libre de supprimer la référence d'objet ("variable") à tout moment après sa dernière utilisation, ce n'est donc pas nécessairement vrai. p>
Tant que la référence à l'objet existe sur la pile, elle ne sera pas recueillie p> blockQuote>
Ceci est vrai - mais le JIT peut changer lorsque cette variable n'est plus "existante sur la pile" d'une manière qui ne correspond pas nécessairement à votre code. P>
en C # 5, cela peut être vraiment déroutant, aussi bien, que
async code> peut être réécrit de manière à ce que les variables collent plus longtemps que prévu dans certains scénarios. P>Cela étant dit, si vous devez garantir qu'un objet est éligible à un moment donné, définissez la ou les variable (s) référencée de l'objet à
null code> explicitement vous permet de contrôler exactement quand il devient éligible explicitement. p>
Cependant, selon cette conférence de UC Berkley, tant que la référence à l'objet existe sur la pile, elle ne sera pas recueillie. p>
Tu as raison. Ce qui vous manque, c'est qu'une référence n'existe plus sur la pile. P>
pour le code qui construit un objet sur la pile: p>
xxx pré> le variable
refn code> est stocké sur la pile, dans certains em> emplacement de mémoire: p>xxx pré> vient maintenant la ligne suivante: P>
Stack Pointer -> 0x403730: pointer to ref2 0x40372C: pointer to ref1 0x403728: saved value of EBP 0x403724: saved value of return address 0x403720
Je ne sais pas pourquoi cela a été évité, je n'ai pas lu le code avec précaution pour voir s'il y avait une erreur. Mais je me sens comme une manière trop compliquée d'expliquer un concept relativement simple (au moins, en théorie, peut-être pas dans la mise en œuvre, mais nous ne sommes pas écrire i> GC ici).
Qu'est-ce que EBP? Vous mentionnez une "valeur enregistrée de EBP" dans votre explication
Les autres valeurs sont vraiment sans importance; Je viens de lancer dans "possible" i> valeurs que l'on pourrait voir sur une pile. Dans ce cas, j'ai jeté le jargon Pointeur de base i> (abrégé EBP). Par convention, il pointe de l'endroit où la pile était lorsque la fonction a été appelée (de sorte que le pointeur de pile (ESP) puisse être renvoyé lorsque la fonction renvoie). J'aurais pu facilement dire up code>, down code>, étrange code> ou charmé code> comme étiquettes pour les autres choses; Je voulais juste quelque chose sorta i> réel pour mes supports maquillés.
Ceci est le code CIL généré à partir de cette méthode:
Lire ce Article MSDN , vous apprendrez comment cela fonctionne dans les détails .
Je pense que la réponse acceptée manque le point. La "pile" que vous voyez dans l'IL est pas b> la même chose que la "pile" que la CPU voit. Ce n'est qu'une chose logique utilisée pour décrire le calcul; ça n'existe pas réellement. Ce n'est là que là-bas comme une simplification; Le code est optimisé avant d'être jit'ed à l'assemblage.
Chapitre 3 "Concepts de base", section 3.9 "Gestion de la mémoire automatique" dans la spécification de langue C # officielle répond à votre question. Vous pouvez le télécharger à partir de Microsoft. Microsoft.com/en-us/download/confirmation.aspx? id = 7029 . Il m'a fallu quelques minutes pour vérifier. Combien de temps avez-vous composé votre question?
Si vous voulez demander quel libération de la mémoire implique, demandez-la précisément que. Je ne sais pas sur Java, mais la spécification de la langue C # est claire. Il spécifie quand un objet est admissible à la collecte et il est dit que la collecte actuelle devrait se produire à un moment donné après le moment de devenir éligible, ce qui signifie à tout moment après le moment de devenir éligible. La fraction d'une nanoseconde après est aussi après. Cela ne dit rien à propos des piles. De tels détails de mise en œuvre ne sont pas pertinents. Si la spécification Java dit à propos de la pile, il est clairement différent.