2010-10-14 5 views

Répondre

3

La mémoire sur le tas est gérée par le garbage collector. La mémoire de la pile est déterministe et est renvoyée au pool lorsqu'elle est hors de portée.

+0

"détruit" est peut-être un peu fort. Ignoré, peut-être. Mais à moins que le fil se termine, il se trouve principalement là. –

+0

@ Marc, je ne pouvais pas trouver un bon moyen de le mettre. Êtes-vous d'accord avec mon changement? –

+0

Cela dépend de ce que vous entendez par portée ... L'espace de pile peut (facultativement) être effacé quand * entrée * une méthode, mais IIRC il ne meurt rien en quittant. Donc, cela laisse juste stack-teardown à la fin du thread. –

3

Juste le tas (géré). La pile peut avoir références aux objets, mais pas les objets eux-mêmes.

0

Cela dépend du niveau d'abstraction que vous envisagez. À un niveau géré, il existe un seul «tas géré», mais il est en fait divisé en tampons distincts pour prendre en charge la récupération de place générationnelle. Il existe également un tas non géré, à partir duquel le code non géré peut allouer de la mémoire dans l'ignorance béate du CLR. Tout cela est mis en œuvre avec un espace mémoire de processus sous-jacent du système d'exploitation dans lequel vivent tous les différents tas. L'histoire est compliquée par le fait que le GC peut compacter ses différents tas dans le cadre de la collecte. Lorsque cela se produit, le GC déplace la mémoire, ce qui signifie que les pointeurs peuvent être invalidés. Afin de répondre à cette demande, le GC se réserve le droit de modifier les références tout au long de la demande pour indiquer l'emplacement exact. Dans ce sens, le GC gère aussi la 'pile', puisque les références stockées sur la pile peuvent changer à l'endroit où elles pointent.

Questions connexes