Хорошо, я понимаю, что такое стек и куча (значения находятся в стеке, ссылки в куче
Не думаю, что вы понимаете, что такое стек и куча.Если значения находятся в стеке, то где находится массив целых чисел? Целые числа являются значениями. Вы говорите мне, что массив целых чисел сохраняет свои целые числа в стеке? Когда вы возвращаете массив целых чисел из метода, скажем, с десятьюТысячи целых чисел в нем, вы говорите мне, что эти десять тысяч целых чисел скопированы в стек?
Значения живут в стеке, когда они живут в стеке, и живут в куче, когда они живут в куче.Идея о том, что тип вещи имеет отношение к времени ее хранения , не имеет смысла. Места хранения, которые недолговечны , идут в стек;местоположения, которые долгоживущие идут в куче, и это не зависит от их типа. Долгоживущий int должен идти в куче, так же как и долгоживущий экземпляркласса.
Когда я объявляю новый экземпляр класса, он живет в куче, со ссылкой на эту точку в памяти в стеке.
Почему ссылка должна идти в стек?Опять же, время хранения ссылки не имеет ничего общего с ее типом .Если хранилище ссылки является долгоживущим, то ссылка остается в куче.
Я также знаю, что C # выполняет собственную сборку мусора (т. Е. Определяет, когда экземпляра класса больше нет виспользовать и восстанавливать память).
Язык C # не делает этого;CLR делает это.
Правильно ли я понимаю сборщик мусора?
Вы, кажется, верите в ложь о стеке и куче, так что шансы хороши нет, это не так.
Могу ли я сделать свою собственную?
Нет в C #, нет.
Я спрашиваю, потому что у меня есть метод в цикле For.Каждый раз, когда я прохожу цикл, я создаю новый экземпляр моего класса.Я мысленно представляю себе, как все эти классы лежат в куче, ничего не делая, но забирая память, и я хочу как можно быстрее избавиться от них, чтобы все было аккуратно и аккуратно!
Весь смысл сбора мусора состоит в том, чтобы избавить вас от беспокойства по поводу уборки.Вот почему это называется "автоматическая сборка мусора".Это приводит вас в порядок.
Если вы беспокоитесь, что ваши циклы создают давление сбора , и вы хотите избежать давления сбора из соображений производительности, тогда я советую вам использовать объединение стратегия.Было бы разумно начать со стратегии явного пула;то есть:
while(whatever)
{
Frob f = FrobPool.FetchFromPool();
f.Blah();
FrobPool.ReturnToPool(f);
}
, а не пытаться выполнить автоматический пул с помощью воскрешающего финализатора.Я не советую как финализаторам, так и воскресению объектов в целом, если вы не являетесь экспертом по семантике финализации.
Пул, конечно, выделяет нового Frob, если в пуле его нет.Если он есть в пуле, он раздает его и удаляет из пула до тех пор, пока он не будет помещен обратно. (Если вы забудете поместить Frob обратно в пул, GC в конечном итоге доберется до него.) Продолжаястратегия объединения: вы заставляете GC в конечном итоге перемещать всех фробов в кучу второго поколения вместо того, чтобы создавать большое давление сбора в куче нулевого поколения.Затем давление сбора исчезает, потому что новые Лягушки не выделяются.Если что-то еще создает давление при сборе, все Лягушки благополучно находятся в куче второго поколения, где их редко посещают.
Это, конечно, полная противоположность стратегии, которую вы описали;весь смысл стратегии объединения в пул состоит в том, чтобы вызывать бесконечное зависание объектов .Объекты, нависающие вечно, - это хорошая вещь, если вы собираетесь их использовать.
Конечно, не делайте такого рода изменений, пока не узнаете через профилирование, что у вас проблема с производительностью из-за давления при сборе!Редко иметь такую проблему на настольном CLR;это гораздо чаще встречается на компактном CLR.
В целом, если вы тот человек, который чувствует себя некомфортно, когда в вашем расписании убирается диспетчер памяти, тогда C # не подходит,Вместо этого рассмотрим С.