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

Глава.21 .Автоматическое.управление.памятью.(уборка.мусора)
вызывая соответствующие методы финализации. Особенности работы данного 
потока запрещают исполнять в методе финализации любой код, имеющий какие-
либо допущения о потоке, исполняющем код. Например, в методе финализации 
следует избегать обращения к локальной памяти потока.
Очередь на финализацию
Список финализации
Управляемая куча
A
C
D
E
F
I
J
E
J
I
C
F
Корни:
поля и переменные
рис. 21.14.
.Управляемая.куча.с.указателями,.перемещенными.из.списка.
финализации.в.очередь.на.финализацию
Возможно, в будущем, CLR будет поддерживать множественные потоки фина-
лизации, поэтому следует избегать создания кода, в котором методы финализации 
вызываются последовательно. При наличии всего лишь одного потока финали-
зации могут возникнуть проблемы производительности и масштабируемости 
в ситуации, когда финализируемые объекты распределяются между несколькими 
процессорами, но лишь один поток исполняет методы финализации — он может 
просто не успеть.
Взаимодействие списка финализации и очереди на финализацию само по себе 
замечательно, но сначала я расскажу, почему эта очередь получила свое оригинальное 
название. Очевидно, буква «f» означает «finalization», то есть «финализация»: каждая 
запись в очереди — это ссылка на объект в управляемой куче, для которого должен 
быть вызван метод финализации. Вторая часть оригинального имени, «reachable», 
означает, что эти объекты доступны. То есть ее можно было бы назвать очередью 
ссылок на объекты, доступные для финализации, но для краткости мы будем назы-
вать ее очередью на финализацию. Эту очередь можно рассматривать и просто как 
корень, подобно статическим полям, которые являются корнями. Таким образом, 
находящийся в очереди на финализацию объект доступен и 
не
является мусором.
Короче говоря, если объект недоступен, уборщик считает его мусором. Далее, 
когда уборщик перемещает ссылку на объект из списка финализации в очередь на 
финализацию, объект перестает считаться мусором, а это означает, что занятую 
им память освобождать нельзя. На этом этапе уборщик завершает поиск мусора, 
и некоторые объекты, идентифицированные как мусор, перестают считаться тако-
вым — они как бы 
воскресают
.

---

597
Мониторинг.и.контроль.времени.жизни.объектов
По мере маркировки объектов из очереди другие объекты, на которые ссылаются 
их поля ссылочного типа, также рекурсивно помечаются — все эти объекты должны 
пережить уборку мусора. На этой стадии уборщик мусора завершил выявление 
мусора, а некоторые объекты, отнесенные к мусору, были воскрешены. Уборщик 
мусора сжимает освобожденную память, воскрешенные объекты переводятся 
в более старое поколение, а особый поток CLR очищает очередь на финализацию, 
выполняя метод финализации для каждого объекта из очереди.
Вызванный снова, уборщик обнаруживает, что финализированные объекты стали 
мусором, так как ни корни приложения, ни очередь на финализацию больше на них 
не указывают. Память, занятая этими объектами, попросту освобождается. Важно 
понять, что для освобождения памяти, занятой объектами, требующими финализа-
ции, уборку мусора нужно выполнить дважды. На самом деле может понадобиться 
и больше операций уборки мусора, поскольку объекты переходят в следующее по-
коление (но об этом — чуть позже). На рис. 21.15 показан вид управляемой кучи 
после второй уборки мусора.