Цель: Изучение назначения процедуры сборки мусора

Задачи:

1. Познакомиться с обобщенной схемой сборки мусора.

2. Дополнить глоссарий терминов терминологией по данной теме.

Содержание темы:

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

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

В некоторый момент во время выполнения программы среда CLR может освободить память, выделенную для недостижимых объектов. Объект считается “недостижимым”, когда на него нет никаких ссылок.

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

Сборщик мусора включается, когда код может напрямую запросить сбор мусора у CLR, например, при явном вызове метода сборки мусора GC.Collect() (инициирует немедленный сбор мусора). Хотя Microsoft настоятельно не рекомендует так поступать, порой имеет смысл, чтобы приложение заставило CLR выполнить сбор мусора.

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

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

После обнаружения всех достижимых объектов сборщик мусора проверяет возможность применения для всех, недостижимых объектов метода Оbject.Finalize. Метод Object.Finalize (завершитель) позволяет объекту освободить ресурсы и выполнить другие операции завершения (finalization) непосредственно перед его удалением из памяти.

У завершителей есть несколько недостатков:

•  этот механизм потребляет процессорное время. Выделение завершаемых объектов занимает больше времени, так как указатели на них должны быть размещены в списке завершения. Поэтому не стоит его использовать, если очистка не нужна.
•  принуждая сборщик мусора исполнить метод Finalize, можно вызвать значительное снижение производительности. Помните: завершаются все объекты, поэтому если в массиве 10 000 объектов, метод Finalize будет вызван у каждого из них.
•  завершаемый объект может ссылаться на другие объекты (как завершаемые, так и незавершаемые), излишне продлевая им жизнь.

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

Команда промежуточного языка (IL) newobj создает объект. Многие языки (включая С# и Visual Basic) предлагают оператор new, заставляющий компилятор генерировать команду newobj и поместить ее в IL-код метода. Получив команду newobj, CLR выполняет следующие действия:

1. Подсчитывает число байтов, необходимое для полей типа (и всех полей его базового типа).

2. Прибавляет к полученному значению число байтов, необходимых для системных полей объекта.

3. Проверяет, хватает ли в зарезервированной области доступных байтов, чтобы выделить память для объекта. Если объект умещается, для него выделяется память по адресу, на который указывает NextObjPtr. Далее вызывается конструктор типа (которому передается NextObjPtr параметром this), и IL-команда newobj (или оператор new) возвращает адрес объекта. Перед возвратом адреса объекта указатель NextObjPtr передвигается на первый адрес после объекта, в результате он указывает адрес, по которому в куче будет размещен следующий объект.

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

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

У каждого приложения есть набор корней (roots). Корень – это адрес, по которому находится указатель на ссылочный тип в памяти. Этот указатель ссылается на объект в управляемой куче, либо его значение null. Например, все глобальные или статические переменные ссылочных типов считаются корнями. Любая локальная переменная или переменная-параметр в стеке потока также считается корнем. Наконец, регистр процессора со ссылкой на объект ссылочного типа также считается корнем в пределах метода.

Начиная работу, сборщик предполагает, что все объекты в куче – мусор. Иначе говоря, он предполагает, что ни один из корней приложения не ссылается на объекты в куче. Затем сборщик проходит по корням, строя граф всех достижимых объектов.

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

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

Сбор мусора вызывает существенное снижение производительности – это основной недостаток управляемой кучи. Однако имейте в виду что сбор мусора начинается только после заполнения поколения 0.