Должен ли я когда-либо вручную принудительно собирать мусор в моем приложении WPF?

Я только что разбирал утечки памяти в своем приложении WPF. Для этого я использовал профилировщик CLR, а также просмотрел статистику процесса в диспетчере задач Windows. Мой основной тест состоял в том, чтобы убедиться, что когда определенное окно было закрыто, оно все еще не зависало в памяти.

Я немного новичок в разработке Windows, и сначала я сбивался с толку, потому что в простом тестовом приложении казалось, что, несмотря ни на что, мои окна всегда оставались в памяти после закрытия. Но в конце концов я решил, что это не означает, что произошла утечка памяти, но просто, что они еще не были собраны мусором. Поэтому я должен был создать кнопку в моем главном окне, подключенном к обработчику событий, содержащему код для принудительной сборки мусора вручную. Благодаря сбору мусора вручную я смог выполнить тесты на утечку памяти, и я все отсортировал.

Но это заставило меня задуматься - есть ли необходимость вручную принудительно собирать мусор?

Мне больно видеть, как потребление памяти приложения увеличивается и открывается, когда я открываю и закрываю окна. Конечно, в конце концов, сбор мусора автоматически запускается, и все это сортируется. Но кажется, что это хорошая идея вручную собрать мусор после закрытия этих тяжелых окон. Но есть ли смысл? У меня возникает ощущение, что тестирование в стороне, мы не должны принуждать сбор мусора - просто дайте системе разобраться в этом.

Мысли оценили.

ОТВЕТЫ

Ответ 1

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

Я действительно с тех пор нашел хороший ответ на мой вопрос в книге, которую я имею на платформе .NET. В нем говорится:

Вся цель мусора .NET коллекционер - управлять памятью на нашем от имени. Однако в некоторых очень редких случаях обстоятельства, может быть полезно программно заставлять мусор коллекция используя GC.Collect(). В частности:

  • Когда ваше приложение вот-вот войдет в блок кода, который вы не используете хочу прервать возможный мусор коллекция.
  • Когда ваше приложение только что закончило выделение чрезвычайно большого количества объектов, и вы хотите удалить их как большую часть приобретенной памяти, как только возможно.

Ответ 2

Хорошая практика никогда не принуждает сбор мусора вручную, в любом приложении .NET. GC считается умнее нас (и на самом деле он умный). К сожалению, если есть утечка памяти, даже вызов принудительно GC не помогает.

Ответ 3

Я согласен с вами по обеим сторонам вашей точки:-). Обычно я придерживаюсь такого подхода, что люди, написавшие среду выполнения .NET, умнее меня и лучше понимают сбор мусора, чем я, поэтому я оставляю это в покое.

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

Ответ 4

Единственный раз, когда я использую GC.Collect, нужно быстро узнать, сколько памяти будет готово к сбору.

В противном случае это бесполезно, потому что до сих пор GC более умный, чем я.

Ответ 6

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