выделение памяти c# и шаблоны освобождения
Так как C# использует Сборку "мусора". Когда необходимо использовать.Dispose для освобождения памяти?
Я понимаю, что существует несколько ситуаций, таким образом, я попытаюсь перечислить тех, я могу думать.
- Если я закрываю Форму, которая содержит текстовый объект GUI, те объекты разыменовываются и поэтому будут собраны?
- Если я создаю локальный объект, использующий новый, должен я.Dispose его перед выходами метода или просто позволить GC заботиться о нем? Что такое хорошая практика в этом случае?
- Есть ли какие-либо времена, в которые принуждение GC понятно?
- События собраны GC, когда это - объект, собран?
5 ответов
Теоретически, если вы правильно определили компоненты, никогда не должно требоваться вызывать Dispose () для ваших объектов, как это должен делать финализатор в конце концов позаботится об этом.
При этом каждый раз, когда вы используете объект, реализующий IDisposable, рекомендуется вызывать Dispose () для объекта, как только вы закончите работу с ним.
По некоторым конкретным вопросам:
1) Если вы знаете, что «закончили» с формой, вы можете вызвать для нее Dispose (). Это вызовет очистку в этот момент неуправляемых ресурсов, связанных с формой.
2) В этом случае: если ваш объект просто используется в этом методе, используйте вместо этого «using»:
using (MyObject myObject = new MyObject())
{
// use your object
} // It'll be disposed of here for you
3) Есть редкие причины для этого, но в целом нет.
4) События являются делегатом - память, связанная с делегатом, будет собрана после того, как сам делегат станет некорневым, что обычно происходит, когда рассматриваемые объекты не имеют root-доступа.
Вы должны вызвать Dispose для каждого класса, реализующего IDisposable . Если бы его не нужно было Dispose , то он не реализовал бы IDisposable .
Что касается других ваших вопросов:
- Когда вы добавляете элемент управления в коллекцию
Controlsформы, то этот элемент управления будет автоматически удален при закрытии формы, поэтому вам ничего не нужно там делать . - Если объект реализует
IDisposable, необходимо вызватьDispose. Например, если вы перейдете кnew FileStream (...), то нужно удалить FileStream, поскольку он реализует IDisposable. Я предлагаю вам ознакомиться с конструкциейusingв C #, которая упрощает работу с объектамиIDisposable. - Нет, в 99,99% случаев сборщик мусора знает, когда лучше всего запускаться. Это одна из тех ситуаций, когда «ты узнаешь, когда тебе это понадобится».
- Когда на объект, содержащий событие, больше не ссылаются, то логически любые ссылки на объекты, содержащиеся в событии, также больше не упоминаются и будут доступны для сбора.
Если вы используете объект IDisposable , рассмотрите возможность использования оператора using для автоматической обработки удаления для ты.
Посмотрите на этот вопрос:
Есть ли общепринятая практика, как упростить освобождение памяти для сборщика мусора в .NET?
Если ваш класс создает экземпляр интерфейса IDisposable, это (вероятно) означает, что у него есть система ресурсы, которые необходимо утилизировать напрямую. Один из простых способов добиться этого - использовать ключевое слово using, например:
using(var g = Graphics.FromBitmap(bmp))
{
//Do some stuff with the graphics object
}
на ответ @Matt S в том вопросе, на который я ссылался.
На ваши вопросы:
- Если вы создаете экземпляр объекта с IDisposable, вам нужно будет удалить его при закрытии формы. Это сложно в WPF и просто в Winforms, поскольку диалоговые окна winforms имеют методы Dispose. Для WPF я решил проблему, сохранив класс WPF, но скрытый, вызвав метод удаления, который удаляет все объекты (например, последовательные порты), а затем устанавливает для класса WPF значение null.
- Нет. Пусть об этом позаботится сборщик мусора.
- Думаю, да, но я получил отрицательные голоса :) Когда я сделал очень большие выделения, принудительное удаление их из GC - хорошая идея.
- Я не уверен. Я думаю, что события сами по себе являются объектами, поэтому они будут собираться, когда больше не используются.
Как сказал Рид Копси, обычно нет необходимости вызывать Dispose.
Возможный случай, который может создавать вашу проблему, заключается в том, что статический объект хранит ссылки на другие объекты, которые больше нигде не используются. Следующий код показывает пример:
Form_Load(...)
MyState.Instance.AddressChanged += this.User_AddressChanged;
End
Если по какой-то причине, когда форма выгружается, код не отменяет регистрацию обработчика события, на экземпляр формы все еще будет ссылаться объект state.