Применение опыта разработки в управлении памятью
Обновлен: Ноябрь 2007
Подходы к управлению памятью могут различаться в зависимости от имеющегося опыта разработки. В определенных ситуациях разработчику придется приспосабливать свои приемы программирования к возможностям автоматического управления памятью, предоставляемым средой CLR.
Разработчики модели COM
Разработчики, использующие модель COM, привыкли в качестве средства ручного управления памятью использовать счетчики ссылок. При каждом обращении к объекту значение счетчика увеличивается. Когда ссылка на объект выходит из области действия, значение счетчика уменьшается. Если счетчик ссылок на объект достигает нуля, объект уничтожается и его память освобождается.
Схема подсчета ссылок является источником многочисленных ошибок. Если правила подсчета ссылок соблюдаются недостаточно точно, могут преждевременно освобождаться нужные объекты и наоборот, объекты, на которые нет ссылок, могут накапливаться в памяти. Также распространенным источником ошибок являются циклические ссылки. Циклическая ссылка возникает, если дочерний объект ссылается на родительский объект, а родительский объект ссылается на дочерний. В такой ситуации становится невозможным освобождение памяти или уничтожение объекта. Единственным решением будет установить фиксированные правила использования и удаления для родительских и дочерних объектов, например потребовать, чтобы родитель всегда сначала удалял своего потомка.
Если приложения разрабатываются на языке, предназначенном для работы в среде CLR, сборщик мусора этой среды устраняет необходимость в подсчете ссылок. В результате исключаются ошибки, которые могут возникать в случае применения этой схемы ручного управления памятью.
Разработчики на C++
Разработчики программ на языке C++ привыкли решать задачи, связанные с ручным управлением памятью. В языке C++ память, выделенная для объекта с помощью оператора new, должна освобождаться с помощью оператора delete. Это может приводить к таким ошибкам как утечка памяти, если разработчик забудет освободить объект, или попытка обращения к памяти, занимаемой уже удаленным объектом.
При разработке приложений на Visual C++ или другом языке, предназначенном для работы в среде CLR, для освобождения объекта не нужно использовать оператор delete. Сборщик мусора делает это автоматически, если объект более не используется приложением.
Разработчики на языке C++ склонны избегать использования краткосрочных объектов по причине высоких затрат, сопряженных с ручным управлением памятью для этих объектов. Для управляемых краткосрочных объектов, которые вскоре после создания выходят из области действия коллекций, затраты на выделение и освобождение памяти чрезвычайно низки. В платформе .NET Framework сборщик мусора фактически оптимизирован для управления объектами с кратким временем жизни. При разработке управляемых приложений рекомендуется использовать краткосрочные объекты там, где это позволит упростить программный код.
Разработчики на Visual Basic
Разработчики на языке Visual Basic привыкли к автоматическому управлению памятью. Все знакомые им приемы программирования применимы и к большинству управляемых объектов, создаваемых в платформе .NET Framework. Однако следует особо подчеркнуть рекомендуемый шаблон разработки для метода Dispose, который применяется для создания и использования объектов, инкапсулирующих неуправляемые ресурсы.
Помимо описанных выше, платформа .NET Framework поддерживает другие языки, предназначенные для работы в среде CLR. Независимо от используемого управляемого языка, сборщик мусора .NET Framework обеспечивает автоматическое управление памятью. Он выделяет и освобождает память для управляемых объектов и в случае необходимости вызывает методы Finalize и деструкторы для правильной очистки неуправляемых ресурсов. Автоматическое управление памятью упрощает разработку, исключая распространенные ошибки, которые возникают в случае применения схем ручного управления памятью.
См. также
Основные понятия
Методы "Finalize" и деструкторы