Net framework 5, а также среды Visual Studio 2012 и C#

Глава.21 .Автоматическое.управление.памятью.(уборка.мусора)
CLR проверяет все корни в этом объекте и маркирует объекты, на которые они 
ссылаются. Встретив уже маркированный объект, уборщик мусора останавливается, 
чтобы избежать возникновения бесконечного цикла в случае циклических ссылок.
На рис. 21.2 показана куча с несколькими объектами, в которой корни прило-
жения напрямую ссылаются на объекты 
А
, 
С
, 
D
и 
F
. Все эти объекты маркируются. 
При маркировке объекта 
D
уборщик мусора обнаруживает, что в этом объекте есть 
поле, ссылающееся на объект 
H
, поэтому объект 
H
также помечается. Затем уборщик 
продолжает рекурсивный просмотр всех достижимых объектов.
рис. 21.2.
.Управляемая.куча.до.уборки.мусора
После проверки всех корней куча содержит набор маркированных и немаркиро-
ванных объектов. Маркированные объекты переживут уборку мусора, потому что 
на них ссылается хотя бы один объект; можно сказать, что они достижимы из кода 
приложения. Немаркированные объекты недостижимы, потому что в приложении 
не существует корня, через который приложение могло бы к ним обратиться.
Теперь, когда CLR знает, какие объекты должны остаться, а какие можно уда-
лить, начинается следующая фаза уборки мусора, называемая 
сжатием
(compacting 
phase). В этой фазе CLR перемещает вниз все «немусорные» объекты, чтобы 
они занимали смежный блок памяти. Перемещение имеет много преимуществ. 
Во-первых, оставшиеся объекты будут находиться поблизости друг от друга; это 
приводит к сокращению размера рабочего набора приложения, а следовательно, 
повышает производительность обращения к этим объектам в будущем. Во-вторых, 
свободное пространство тоже становится непрерывным, что позволяет освободить 
эту область адресного пространства. Наконец, сжатие позволяет избежать проблем 
фрагментации адресного пространства при использовании управляемой кучи.
После перемещения в памяти все ссылки на «выжившие» объекты из корней 
указывают на прежнее местонахождение объекта в памяти, а не на тот адрес, по 
которому объект был перемещен. Если возобновить выполнение потоков на этой 
стадии, потоки обратятся по старым адресам, что приведет к некорректному ис-
пользованию памяти. Разумеется, этого допускать нельзя, поэтому в фазе сжатия 
CLR вычитает из каждого корня количество байт, на которое объект был сдвинут 

---

559
Управляемая.куча
вниз в памяти. Тем самым гарантируется, что каждый корень будет ссылаться на тот 
же объект, что и прежде; просто сейчас этот объект оказался в другом месте памяти.
После сжатия памяти кучи в указатель 
NextObjPtr
управляемой кучи заносится 
первый адрес за последним объектом, не являющимся мусором. По этому адресу 
следующий новый объект будет размещен в памяти. На рис. 21.3 показана управ-
ляемая куча после сжатия. После завершения фазы сжатия CLR возобновляет вы-
полнение потоков приложения, а они обращаются к объектам так, словно никакой 
уборки мусора и не было.