Собирает ли сборщик мусора стековую память, кучную память или и то и другое? - PullRequest
13 голосов
/ 26 марта 2010

Я прочитал много статей о сборке мусора, и почти вся статья рассказывает о куче памяти. поэтому мой вопрос «сборка мусора собирает стековую память или кучную память или оба».

Ответы [ 8 ]

17 голосов
/ 26 марта 2010

Собирает кучу памяти.Обычно стековая память собирается автоматически , когда путь выполнения достигает конца области.Например:

void fun()
{
  int n; // reservation on the stack as part of the activation record
  ...
} // returning the stack pointer to where it was before entering the scope

На самом деле, в языке, подобном C ++, переменные, выделенные для стека, называются auto переменными.

10 голосов
/ 26 марта 2010

куча памяти.

Сборка мусора - это метод освобождения памяти, который больше не используется. Иногда часть «больше не используется» является хитрой. Со стеком, как только функция вернется, мы можем быть уверены (исключая ошибку программиста), что локальные переменные больше не используются, поэтому они автоматически освобождаются в это время практически в каждом языке / среде выполнения.

5 голосов
/ 26 марта 2010

Стек называется «стеком» именно потому, что это зона памяти, которая управляется с помощью «политики стека», то есть LIFO (как Last In, First Out). Если распределение в стеке не было выполнено «стековым способом», оно не будет называться стеком, а будет кучей.

Сборка мусора была изобретена для того, чтобы справиться с проблемой размещения вещей в куче, то есть так, чтобы вы не могли предсказать, какие части будут выпущены первыми. GC предназначен для проблем с выделением памяти, когда управление стеками недостаточно.

2 голосов
/ 26 марта 2010

Стек является последним в первом из , поэтому нет необходимости собирать мусор.

- исправлено - дух!

1 голос
/ 26 марта 2010

Если вы не используете профилировщик, о котором никто из нас не знает, куча является основной проблемой. Это потому, что большинство людей просто реагируют на то, что им говорит известный инструмент. Пожалуйста, прочитайте этот пост, чтобы увидеть, что большинство инструментов профилирования, которые указывают на статически распределенные ошибки памяти, являются обычно правильными. Профилирование должно выходить за рамки простых утечек и сборки мусора.

Позвольте мне привести вам пример на C:

#include <stdlib.h>
#include <string.h>

int main(void)
{
   char *am_i_leaking;

   am_i_leaking = strdup("Now, that's subjective!");

   return 0;
}

Если ОС, которая запускает эту программу, не восстанавливает кучу автоматически, я вызвал проблему. Я не могу вспомнить современную ОС, которая не делает то, что на самом деле используется.

Теперь давайте посмотрим на это:

char *foo(void)
{
    static char bar[1024];
    memset(bar, 0, sizeof(bar));
    snprintf(bar, sizeof(bar -1), "Do wa diddy diddy dum diddy do");

    return bar;
}

Как ваш компилятор распределяет это, ну, в общем, зависит от вашего компилятора. Если вы используете его и можете возиться с результатом, возможно, у вас сломан компилятор. Тем не менее, если в эту функцию одновременно входит 100 потоков, то результат, несомненно, будет мусором, если только мой компилятор не поймет, что я имел в виду , и не введет взаимное исключение или динамическое распределение, и мне не придется об этом беспокоиться, с этого момента мы возвращаемся к куче профилирования.

Короче говоря, при нашей жизни сборка мусора относится к куче. Рассчитывайте на то, что в будущем вам удастся сделать укол в стек и попытаться «оптимизировать» вещи, а затем рассчитывать на то, что эти усилия превратятся в интерпретируемый язык, который потребует куча руководителей.

Это не означает, что игнорирование памяти ошибки - это хорошо, независимо от того, что происходит с хранилищем.

1 голос
/ 26 марта 2010

стек - это место, где лежат аргументы вашего метода и локальные переменные. если вы покидаете метод, указатель стека автоматически уменьшается (или увеличивается в зависимости от конкретной реализации). Это верно для большинства языков программирования.

сборщик мусора в отличие только работает на куче.

0 голосов
/ 26 марта 2010

Вы не цитируете какие-либо конкретные технологии, но использование довольно типично для разных языков.

Сборщик мусора работает только в управляемой куче. В одном процессе может быть несколько куч, некоторые из которых не являются сборщиком мусора.

Переменные, расположенные в стеке, освобождаются при возврате метода. Сборщик мусора будет использовать эти переменные для поиска активных ссылок, но не будет собирать память.

0 голосов
/ 26 марта 2010

По крайней мере, в Java, стек будет автоматически отменен, когда вы покидаете этот кадр стека, поэтому нет необходимости собирать мусор.

Я Java-программист, поэтому у меня нет этой проблемы, но на самом деле в C ++, (я слышал это), вам придется быть осторожным с этим, потому что вы можете размещать объекты в стеке и можете оставить кадр стека, объект будет выделен, и вы больше не сможете его использовать и т. д.

...