Внутренние или вложенные области действия в C# влияют на G C?

Question

Ссылаясь на этот пост в качестве примера, влияет ли внутренняя / вложенная область видимости на G C или управление памятью каким-либо образом? Исходя из точки зрения c ++ или c, все, что объявлено и создано в функции, на которое нигде нет ссылок или объявлено вне определяющей области, обычно освобождается после того, как функция вышла из области видимости. G C делает что-то подобное в этом случае? G C учитывает эти внутренние области? Кроме предотвращения доступа к объявлениям за пределами области действия, я не вижу ничего другого, что обеспечивает эта функция.

Answer 1

Предполагая, что мы просто говорим о ссылочных типах:

влияет ли внутренняя / вложенная область видимости на G C или управление памятью каким-либо образом?

В выпуске: нет, нет. G C не заботится о области действия ваших локальных переменных: он заботится о том, когда к локальной переменной в последний раз обращались Выход переменной go из области видимости или присвоение ей null ничего не дает.

Вот почему существует GC.KeepAlive.

В Debug: Локальные переменные будут поддерживаться в течение всего срока действия метода для облегчения отладки, независимо от области действия.

Помимо предотвращения доступа к объявлениям за пределами области действия, я не вижу ничего другого, что обеспечивает эта функция .

Вот и все. В C#.

редко можно увидеть внутренние области видимости

Answer 2

IIR C, типы значений все еще очищены.

С ссылочными типами все сложнее. Ссылки выходят за рамки, но G C отвечает за очистку самих экземпляров - в конце концов. Видите, запуск G C стоит дорого. В то время как он собирает и завершает, все остальные потоки в этом приложении должны сделать паузу.

В результате G C ленив в работе. Если он запускается только один раз - при закрытии приложения - это идеальный случай. Помимо этого, только специальная стратегия G C, явные вызовы G C .Collect () (которых у вас не должно быть в рабочем коде) или опасность исключения OutOfMemory запустят его.

Когда он запускается, все, что имеет значение для каждого экземпляра, это «у меня есть непрерывная цепочка ссылок на приложение root?» Как долго go он выходил из области действия, не имеет значения (за исключением Optimsations, таких как системы генерации).

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

Answer 3

В C#, как и в C ++, G C обычно не имеет к этому никакого отношения.

Области обычно лежат в стеке, который вообще не управляется G C.
Это поведение отличается только для лямбда-выражений, если вы ссылаетесь на внешнюю область видимости из лямбды, объект создается для переменных области видимости, и этот объект может быть очищен с помощью G C, если оставить лямбда-код.

Сборщик мусора использует следующую информацию, чтобы определить, являются ли объекты живыми:

Корни стека. Переменные стека, предоставляемые компилятором JIT (Just-in-Time) и обходчиком стека. Оптимизация JIT может удлинить или сократить области кода, в которых переменные стека сообщаются сборщику мусора.

Дескрипторы сборки мусора. Обрабатывает, которые указывают на управляемые объекты и которые могут быть выделены кодом пользователя или общеязыковой средой выполнения.

Stati c data. Stati c объекты в доменах приложений, которые могут ссылаться на другие объекты. Каждый домен приложения отслеживает свои объекты c.

Подробнее см .: Основы сборки мусора

А для Lambdas: Локальные функции по сравнению с лямбда-выражениями