Читайте также:
|
"Золотое правило" по управлению памятью в .NET звучит просто:
Правило. После создания, объект будет автоматически удален сборщиком мусора тогда, когда в нем отпадет необходимость. То есть, сборщик мусора удаляет объект из кучи тогда, когда тот становится недостижимым ни в одной части программного кода.
Например:
В этом простом примере, ссылка на объект Car (refToMyCar) была создана непосредственно внутри метода Main() и не передавалась за пределы определяющей области действия (ни в виде возвращаемого значения, ни в виде параметров). Поэтому после завершения вызова данного метода ссылка refToMyCar окажется недостижимой, а объект Саг, соответственно — кандидатом на удаление сборщиком мусора. Следует, однако, понять, что иметь полную уверенность в немедленном удалении этого объекта из памяти сразу же после выполнения метода Main() нельзя. Все, что в данный момент можно предполагать, так это то, что когда в CLR -среде будет в следующий раз производиться сборка мусора, объект refToMyCar может подпасть под процесс уничтожения.
Программирование в среде с автоматической сборкой мусора значительно облегчает разработку приложений. Программистам на C++ хорошо известно, что если они специально не позаботятся об удалении размещаемых в куче объектов, вскоре обязательно начнут возникать "утечки памяти". На самом деле отслеживание проблем, связанных с утечкой памяти, является одним из самых длительных (и утомительных) аспектов программирования в неуправляемых средах. Благодаря назначению ответственным за уничтожение объектов сборщика мусора, обязанности по управлению памятью, по сути, сняты с плеч программиста и возложены на CLR -среду.
Дата добавления: 2015-07-25; просмотров: 84 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Время жизни объектов | | | CIL-код, генерируемый для ключевого слова new |