Sources.RU Magazine Поиск по журналу
 

TopList

Сборка мусора в .NET Framework

Автор: DeVoid

Сборщик мусора - это ответ .NET на вопросы управления памятью, в частности, на вопрос о том, что делать с восстановлением памяти, которую запрашивает приложение. До настоящего времени на платформе Windows использовалось две технологии освобождения памяти, выделенной системой по динамическим запросам:

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

    Поддержка счетчиков ссылок - это техника, которая используется в COM. Идея заключается в том, что каждый компонент COM поддерживает счетчик клиентов, которые в данный момент ссылаются на него. Когда значение счетчика падает до нуля, компонент может уничтожить себя и освободить ассоциированную с ним память и ресурсы. При таком подходе проблема сводится к обязанности клиента "корректно себя вести" и вовремя извещать компонент о том, что он завершил с ним работать. Стоит одному клиенту не сделать этого, и объект останется в памяти. Иногда эта проблема потенциально более серьезна, чем простая утечка памяти в С++, потому что COM-компонент может существовать внутри своего собственного процесса, а это значит, что он никогда не будет удален системой.

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

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

    Одно важное свойство сборки мусора заключается в том, что это недетерминированный процесс. Другими словами, вы не можете знать, когда будет вызван сборщик мусора; он будет вызван тогда, когда среда CLR решит, что в этом есть необходимость, хотя возможно перекрыть этот процесс и вызвать сборщик мусора из вашего приложения


    С уважением, DeVoid!
    ( Cайт автора )



    Если у Вас возникли проблемы, вопросы или пожелания к статье – милости просим в тему поддержки этой статьи.




     Design by Шишкин Алексей (Лёха)  ©2004-2008 by sources.ru