27. Жизненный цикл объектов. Алгоритм «сборки мусора» Жизненный цикл объектов

В С# общий принцип управления памятью формулируется очень просто: для создания объекта в области «управляемой кучи» (managed heap) используется ключевое слово new. Среда выполнения .NET автоматически удалит объект тогда, когда он больше не будет нужен. Правило в целом вполне понятно, однако возникает один дополнительный вопрос: а как среда выполнения определяет, что объект больше не нужен? Короткий (то есть неполный) ответ гласит, что среда выполнения удаляет объект из памяти, когда в текущей области видимости больше не остается активных ссылок на этот объект.

Вне зависимости от того, насколько осторожно вы будете создавать объекты, как только место в управляемой куче заканчивается, автоматически запускается сборщик мусора (garbage collector, GC). Сборщик мусора оценивает все объекты, размещенные в настоящий момент в управляемой куче, с точки зрения того, есть ли в области видимости приложения активные ссылки на них. Если активных ссылок на какой -либо объект больше нет или объект установлен в nu11, этот объект помечается для удаления, и в скором времени память, занимаемая подобными объектами, высвобождается.

Сборщик мусора

Сборка мусора — технология, позволяющая, с одной стороны, упростить программирование, избавив программиста от необходимости вручную удалять объекты, созданные в динамической памяти, с другой — устранить ошибки, вызванные неправильным ручным управлением памятью.

В системе со сборкой мусора обязанность освобождения памяти от объектов, которые больше не используются, возлагается на среду исполнения программы. Программист лишь создаёт динамические объекты и пользуется ими, он может не заботиться об удалении объектов, поскольку это делает за него среда. Для осуществления сборки мусора в состав среды исполнения включается специальный программный модуль, называемый «сборщиком мусора». Этот модуль периодически запускается, определяет, какие из созданных в динамической памяти объектов более не используются, и освобождает занимаемую ими память.

Периодичность запуска сборщика мусора определяется особенностями системы. Сборщик может работать в фоновом режиме, запускаясь при неактивности программы (например, когда программа простаивает, ожидая ввода данных пользователем). Сборщик мусора запускается безусловно, прерывая на время своей работы выполнение программы, когда очередную операцию выделения памяти оказывается невозможно выполнить из-за того, что вся доступная память исчерпана. После освобождения памяти прерванная операция выделения памяти возобновляется, и программа продолжает исполняться дальше. Если же оказывается, что освободить память невозможно, среда исполнения останавливает программу с сообщением об ошибке «Недостаточно памяти».

28. Жизненный цикл объектов. Финализаторы

Перед тем, как объект будет удален из памяти запускается его финализатор, если он определен. Финализаторы объявляются как конструкторы, но с префиксом ~. Финализатор не может быть public или static, не может принимать параметры и обращаться к базовому классу.

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

Финализаторы могут быть полезны, но есть ряд отрицательных моментов в их использовании:

• финализаторы замедляют выделение и утилизацию памяти

• финализаторы продлевают время жизни объектов (а также ссылающихся на них объектов)

• порядок вызова финализаторов предсказать невозможно

• момент вызова финализатора контролировать невозможно

• если финализатор приводит к блокировке, другие объекты не смогут выполнить финализацию

• финализатор может вообще не запуститься если приложение завершиться аварийно

Чтобы минимизировать отрицательные моменты, финализаторы должны работать быстро, не блокироваться, не ссылаться на другие финализируемые объекты, не генерировать исключений.