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

Глава 21.
 автоматическое 
управление памятью 
(уборка мусора)
В этой главе рассказано о создании новых объектов управляемыми приложениями, 
о том, как управляемая куча распоряжается временем жизни этих объектов и как 
освобождается занятая ими память. Мы рассмотрим работу уборщика мусора 
общеязыковой среды CLR и проблемы, связанные с его производительностью. 
В конце главы речь пойдет о приемах проектирования приложений, эффективно 
использующих память.
Управляемая куча
Любая программа использует ресурсы — файлы, буферы в памяти, пространство 
экрана, сетевые подключения, базы данных и т. п. В объектно-ориентированной 
среде каждый тип идентифицирует некий доступный этой программе ресурс. Чтобы 
им воспользоваться, должна быть выделена память для представления этого типа. 
Для доступа к ресурсу вам нужно:
1. Выделить память для типа, представляющего ресурс (обычно это делается при 
помощи оператора 
new
в C#).
2. Инициализировать выделенную память, установив начальное состояние ресурса 
и сделав его пригодным к использованию. За установку начального состояния 
типа отвечает его конструктор.
3. Использовать ресурс, обращаясь к членам его типа (при необходимости опера-
ция может повторяться).
4. В рамках процедуры очистки уничтожить состояние ресурса. 
5. Освободить память. За этот этап отвечает исключительно уборщик мусора.
Эта простая на первый взгляд парадигма стала одним из основных источни-
ков ошибок у программистов, которым приходится вручную управлять памятью, 
а именно программистов C++. Программисты, ответственные за управление памя-
тью, хронически забывают освободить память, ставшую ненужной, или пытаются 
использовать уже освобожденную память. При неуправляемом программировании 

---

555
Управляемая.куча
эти два вида ошибок в приложениях опаснее остальных, так как обычно нельзя 
предсказать ни их последствий, ни периодичность их появления. Прочие ошибки 
довольно просто исправить, заметив, что приложение функционирует неправильно.
Если вы пишете код, безопасный по отношению к типам (без использования клю-
чевого слова C# 
unsafe
), повреждение памяти в ваших приложениях невозможно. 
Утечки памяти остаются теоретически возможными, но они не происходят в стан-
дартной ситуации. Как правило, утечки памяти возникают из-за того, что приложение 
хранит объекты в коллекции, но не удаляет их, когда они становятся ненужными.
Ситуация дополнительно упрощается тем, что для большинства типов, регу-
лярно используемых разработчиками, шаг 4 (уничтожение состояния ресурса) не 
является обязательным. Таким образом, управляемая куча, кроме ликвидации уже 
упомянутых ошибок, также предоставляет разработчику простую модель програм-
мирования: программа выделяет и инициализирует ресурс, после чего использует 
его так долго, сколько понадобится. Для большинства типов очистка ресурсов не 
нужна, память просто освобождается уборщиком мусора.
При использовании экземпляров типов, требующих специальной очистки, 
модель программирования остается такой же простой. Впрочем, иногда очистка 
ресурса должна выполняться как можно раньше, не дожидаясь вмешательства убор-
щика мусора. В таких классах можно вызвать дополнительный метод (называемый 
Dispose
), чтобы очистка была выполнена по вашему собственному расписанию. 
С другой стороны, реализация типа, требующего специальной очистки, является 
нетривиальной задачей. Подробности будут изложены позднее в этой главе. Как 
правило, типы, требующие специальной очистки, используют низкоуровневые 
системные ресурсы — файлы, сокеты или подключения к базе данных.