C# - Объекты сразу уничтожаются при выходе из объема?

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

К счастью, также нет реальной причины, по которой вы хотели бы гарантировать это. Если вам нужна память, тогда GC ее восстановит. Если нет, зачем беспокоиться о том, что вокруг все еще есть какой-то мусорный объект? Это не утечка памяти: сборщик мусора может ее найти и очистить в любое время.

Нет, это не гарантируется. Подобно таким языкам, как Java, в C # сборщик мусора запускается, когда это необходимо (то есть когда куча становится слишком полной). Однако, когда ваши объекты реализуют IDisposable , то есть у них есть метод Dispose () , и он должен быть вызван, тогда вы можете воспользоваться преимуществом , используя ключевое слово :

using (var foo = new DisposableObject()) {
    // do something with that
}

Таким образом, Dispose () будет вызываться сразу после выхода из этого с использованием блока .

Примечание: IDisposable встречается во многих типах, большинство особенно GDI +, но также соединения с базой данных, транзакции и т. д., так что это может быть действительно правильный шаблон здесь.

Примечание 2: За кулисами вышеупомянутый блок будет переведен в try / finally блок:

Я не думаю, что вам следует полагаться на сборщики мусора таким образом. Даже если вы отследите, как они работают, вполне возможно, что в следующем выпуске они переопределят это.

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

Это особенно заметно в программах на Java, если посмотреть на потребление памяти в диспетчере задач. Он растет и растет, и внезапно каждую минуту снова падает.

Не думаю, что в этом случае следует полагаться на сборщиков мусора. Даже если вы отследите, как они работают, вполне возможно, что в следующем выпуске они переопределят это.

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

Это особенно заметно в программах на Java, если посмотреть на потребление памяти в диспетчере задач. Он растет и растет, и внезапно каждую минуту снова падает.

Не думаю, что в этом случае следует полагаться на сборщиков мусора. Даже если вы отследите, как они работают, вполне возможно, что в следующем выпуске они переопределят его.

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

Это особенно заметно в программах на Java, если посмотреть на потребление памяти в диспетчере задач. Он растет и растет, и внезапно каждую минуту снова падает.

Это особенно заметно в программах на Java, если посмотреть на потребление памяти в диспетчере задач. Он растет и растет, и внезапно каждую минуту снова падает.

Это особенно заметно в программах на Java, если посмотреть на потребление памяти в диспетчере задач. Он растет и растет, и внезапно каждую минуту снова падает.

Нет. Объект на самом деле не выходит «за пределы области видимости», в отличие от ссылки на него (то есть переменной, которую вы используете для доступа к нему).

Когда больше нет ссылок на данный объект, это объект становится подходящим для сборки мусора (GC) в случае необходимости. Каждый раз, когда сборщик мусора решает, что ему необходимо освободить пространство для вашего объекта, на который больше нет ссылок, тогда будет вызван финализатор объектов.

Если ваш объект является ресурсом (например, дескриптор файла, соединение с базой данных), он должен реализовать Интерфейс IDisposable (который обязывает объект реализовать метод Dispose () для очистки любых открытых соединений и т. Д.). В этом случае лучше всего будет создать объект как часть с использованием блока , так что когда этот блок будет завершен, ваше приложение автоматически вызовет метод objects Dispose () , который позаботится о закрытии вашего файла / соединения с базой данных / чего угодно.

например

using (var conn = new DbConnection())  
{ 
   // do stuff with conn  
} // conn.Dispose() is automatically called here.  

] с использованием блока - это всего лишь синтаксический сахар, который обертывает ваши взаимодействия с объектом conn в блоке try вместе с блоком finally , который только вызывает conn.Dispose ()

Нет. Если вы обратитесь к спецификации CLI (стр. 8.9.6.7 о финализаторах) http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335. недоступен. Полагаясь на давление памяти, чтобы завершение триггера приемлемо, разработчикам следует рассмотреть возможность использования дополнительных метрики

, но не должны.