Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

} // end of method '<Program>$'::'<<Main>$>g__MakeACar|0_0'

Тем не менее, вы должны понимать, что присваивание ссылке значения null ни в коей мере не вынуждает сборщик мусора немедленно запуститься и удалить объект из кучи. Единственное, что при этом достигается — явный разрыв связи между ссылкой и объектом, на который она ранее указывала. Таким образом, установка ссылок в null в C# имеет гораздо меньше последствий, чем в других языках, основанных на С; однако никакого вреда она определенно не причиняет.

Выяснение, нужен ли объект

Теперь вернемся к вопросу о том, как сборщик мусора определяет момент, когда объект больше не нужен. Для выяснения, активен ли объект, сборщик мусора использует следующую информацию.

• Корневые элементы в стеке: переменные в стеке, предоставляемые компилятором и средством прохода по стеку.

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

• Статические данные: статические объекты в доменах приложений, которые могут ссылаться на другие объекты.

Во время процесса сборки мусора исполняющая среда будет исследовать объекты в управляемой куче с целью выяснения, являются ли они по-прежнему достижимыми (т.е. корневыми) для приложения. Для такой цели исполняющая среда будет строить граф объектов, который представляет каждый достижимый объект в куче. Более подробно графы объектов объясняются во время рассмотрения сериализации объектов в главе 20. Пока достаточно знать, что графы объектов применяются для документирования всех достижимых объектов. Кроме того, имейте в виду, что сборщик мусора никогда не будет создавать граф для того же самого объекта дважды, избегая необходимости в выполнении утомительного подсчета циклических ссылок, который характерен при программировании СОМ.

Предположим, что в управляемой куче находится набор объектов с именами А, В, С, D, E, F и G. Во время сборки мусора эти объекты (а также любые внутренние объектные ссылки, которые они могут содержать) будут проверяться. После построения графа недостижимые объекты (пусть ими будут объекты С и F) помечаются как являющиеся мусором. На рис. 9.3 показан возможный граф объектов для только что описанного сценария (линии со стрелками можно читать как "зависит от" или "требует", т.е. Е зависит от G и В, А не зависит ни от чего и т.д.).

После того как объекты помечены для уничтожения (в данном случае С и F, т.к. они не учтены в графе объектов), они удаляются из памяти. Оставшееся пространство в куче сжимается, что в свою очередь вынуждает исполняющую среду изменить лежащие в основе указатели для ссылки на корректные местоположения в памяти (это делается автоматически и прозрачно). И последнее, но не менее важное действие — указатель на следующий объект перенастраивается так, чтобы указывать на следующую доступную область памяти. Конечный результат описанных изменений представлен на рис. 9.4.

На заметку! Строго говоря, сборщик мусора использует две отдельные кучи, одна из которых предназначена специально для хранения крупных объектов. Во время сборки мусора обращение к данной куче производится менее часто из-за возможного снижения производительности, связанного с перемещением больших объектов. В .NET Core куча для хранения крупных объектов может быть уплотнена по запросу или при достижении необязательных жестких границ, устанавливающих абсолютную или процентную степень использования памяти.

Понятие поколений объектов

Когда исполняющая среда пытается найти недостижимые объекты, она не проверяет буквально каждый объект, помещенный в управляемую кучу. Очевидно, это потребовало бы значительного времени, тем более в крупных (т.е. реальных) приложениях.

Для содействия оптимизации процесса каждому объекту в куче назначается специфичное "поколение". Лежащая в основе поколений идея проста: чем дольше объект существует в куче, тем выше вероятность того, что он там будет оставаться. Например, класс, который определяет главное окно настольного приложения, будет находиться в памяти вплоть до завершения приложения. С другой стороны объекты, которые были помещены в кучу только недавно (такие как объект, размещенный внутри области действия метода), по всей видимости, довольно быстро станут недостижимыми. Исходя из таких предположений, каждый объект в куче принадлежит совокупности одного из перечисленных ниже поколений.

• Поколение 0. Идентифицирует новый размещенный в памяти объект, который еще никогда не помечался как подлежащий сборке мусора (за исключением крупных объектов, изначально помещаемых в совокупность поколения 2). Большинство объектов утилизируются сборщиком мусора в поколении 0 и не доживают до поколения 1.

• Поколение 1. Идентифицирует объект, который уже пережил одну сборку мусора. Это поколение также служит буфером между кратко и длительно существующими объектами.

• Поколение 2. Идентифицирует объект, которому удалось пережить более одной очистки сборщиком мусора, или весьма крупный объект, появившийся в совокупности поколения 2.

На заметку! Поколения 0 и 1 называются эфемерными (недолговечными). В следующем разделе будет показано, что процесс сборки мусора трактует эфемерные поколения по-разному.

Сначала сборщик мусора исследует все объекты, относящиеся к поколению 0. Если пометка и удаление (или освобождение) таких объектов в результате обеспечивают требуемый объем свободной памяти, то любые уцелевшие объекты повышаются до поколения 1. Чтобы увидеть, каким образом поколение объекта влияет на процесс сборки мусора, взгляните на рис. 9.5, где схематически показано, как набор уцелевших объектов поколения 0 (А, В и E) повышается до следующего поколения после восстановления требуемого объема памяти.

Если все объекты поколения 0 проверены, но по-прежнему требуется дополнительная память, тогда начинают исследоваться на предмет достижимости и подвергаться сборке мусора объекты поколения 1. Уцелевшие объекты поколения 1 повышаются до поколения 2. Если же сборщику мусора все еще требуется дополнительная память, то начинают проверяться объекты поколения 2. На этом этапе объекты поколения 2, которым удается пережить сборку мусора, остаются объектами того же поколения 2, учитывая заранее определенный верхний предел поколений объектов.

В заключение следует отметить, что за счет назначения объектам в куче определенного поколения более новые объекты (такие как локальные переменные) будут удаляться быстрее, в то время как более старые (наподобие главного окна приложения) будут существовать дольше.

Сборка мусора инициируется, когда в системе оказывается мало физической памяти, когда объем памяти, выделенной в физической куче, превышает приемлемый порог или когда в коде приложения вызывается метод GC.Collect().

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