Собирает ли сборщик мусора стекную память, память кучи или и то, и другое?

Ответ 1

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

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

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

Ответ 2

Память кучи.

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

Ответ 3

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

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

Ответ 4

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

- исправлено-- duh!

Ответ 5

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

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

Ответ 6

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

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

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

int main(void)
{
   char *am_i_leaking;

   am_i_leaking = strdup("Now, that 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 потоков, входящих в эту функцию сразу, конечно, результатом будет мусор, если только мой компилятор не узнает, что я имел в виду, и вводит взаимное исключение или динамическое распределение без меня, чтобы беспокоиться об этом, назад к профилирующей куче.

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

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

Ответ 7

По крайней мере, в java, стек будет автоматически отменен, поскольку вы покинете этот стек стека, поэтому сбор мусора не нужно.

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

Ответ 8

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

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

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