Утечки памяти в .NET

Невозможно предоставить исчерпывающий список ... это очень похоже на вопрос: "Как ты можешь промокнуть?"

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

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

Вы говорите о неожиданном использовании памяти или фактических утечках? Два перечисленных вами случая не совсем утечки; это случаи, когда предметы остаются дольше, чем предполагалось.

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

Обновлено: Или это фактические ошибки в сборщике мусора или неуправляемом коде.

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

Многие вещи, которые могут вызвать утечку памяти на неуправляемых языках, могут по-прежнему вызывать утечки памяти на управляемых языках. Например, плохая политика кеширования может привести к утечке памяти.

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

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

На самом деле это не вызывает утечек, это просто увеличивает работу сборщика мусора:

// slows GC
Label label = new Label();  
this.Controls.Add(label);  
this.Controls.Remove(label);  

// better  
Label label = new Label();  
this.Controls.Add(label);  
this.Controls.Remove(label);  
label.Dispose();

// best
using( Label label = new Label() )
{ 
    this.Controls.Add(label);  
    this.Controls.Remove(label);  
}

Оставление одноразовых компонентов таким образом никогда не является большой проблемой в управляемой среде, такой как .Net - это большая часть того, что означает управляемый.

Конечно, вы замедляете работу своего приложения. Но ничего другого не оставишь.

Исключения в методах Finalize (или вызовах Dispose из Finaliser), которые препятствуют правильному удалению неуправляемых ресурсов. Распространенный из них связан с тем, что программист предполагая, какие объекты порядка будут удалены, и пытается освободить одноранговые объекты, которые уже были удалены, что приводит к исключению, а остальная часть метода Finalize / Dispose from Finalize не вызывается.

Заблокируйте ветку финализатора. Никакие другие объекты не будут собираться мусором, пока поток финализатора не будет разблокирован. Таким образом, объем используемой памяти будет расти и расти.

Дополнительная литература: http://dotnetdebug.net/2005/06/22/blocked-finalizer-thread/

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

Поток финализатора с взаимоблокировкой предотвратит запуск всех оставшихся финализаторов и, таким образом, предотвратит восстановление всех финализируемых объектов (так как они все еще находятся в списке freachable).

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

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

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

Установка свойства GridControl.DataSource напрямую без использования экземпляра класса BindingSource (http://msdn.microsoft.com/en-us/library/system.windows.forms.bindingsource.aspx).

Это вызвало утечки в моем приложении, на отслеживание которых с помощью профилировщика у меня ушло довольно много времени, в конце концов я нашел этот отчет об ошибке, на который Microsoft ответила: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=92260

Забавно, что в документации к классу BindingSource Microsoft пытается выдать его за законный, хорошо продуманный класс, но я думаю, они просто создали его для устранения фундаментальной утечки, касающейся менеджеров валют и привязки данных к элементам управления сеткой.

Остерегайтесь этого, держу пари, что из-за этого существует огромное количество дырявых приложений!

3. Сохранение ссылок на объекты, которые вам больше не нужны.

Повторите другие комментарии - один из способов гарантировать, что Dispose будет вызван, - это использовать using ..., когда это позволяет структура кода.

Чтобы предотвратить утечку памяти .NET:

1) Используйте конструкцию using (или конструкцию try-finally) всякий раз, когда создается объект с интерфейсом IDisposable.

2) Сделайте классы «IDisposable», если они создают поток или добавляют объект в статическую или долгоживущую коллекцию. Помните, что «событие» C# - это коллекция.

Вот небольшая статья о Советы по предотвращению утечек памяти.

Одна вещь, которая была для меня действительно неожиданной:

Region oldClip = graphics.Clip;
using (Region newClip = new Region(...))
{
    graphics.Clip = newClip;
    // draw something
    graphics.Clip = oldClip;
}

Где утечка памяти? Да, вам тоже следовало утилизировать oldClip! Потому что Graphics.Clip - одно из редких свойств, которое возвращает новый одноразовый объект каждый раз, когда вызывается геттер.

У меня есть 4 дополнительных пункта, которые я хочу добавить к этому обсуждению:

1. Завершение потоков (Thread.Abort ()), которые создали элементы управления пользовательского интерфейса без должной подготовки к такому событию, может привести к ожидаемому использованию памяти.

2. Доступ к неуправляемым ресурсам через Pinvoke без их очистки может привести к утечке памяти.

3. Изменение больших строковых объектов. Не обязательно утечка памяти, как только она выходит за рамки, GC позаботится об этом, однако с точки зрения производительности ваша система может пострадать, если большие строки часто изменяются, потому что вы не можете действительно зависеть от GC, чтобы гарантировать, что след вашей программы минимальный.

4. Часто создание объектов GDI для выполнения пользовательского рисования. Если вы часто выполняете работу с GDI, повторно используйте один объект GDI.

У Тесс Фернандес есть отличные сообщения в блоге о поиске и устранении утечек памяти. Лаборатория 6Лаборатория 7