Существует несколько способов, с помощью которых разработчики могут быть пойманы непреднамеренными утечками ресурсов в .NET. Я думал, что было бы полезно собрать их в одном месте.
Пожалуйста, добавьте свои ответы с одним ответом на каждый предмет, поэтому лучше всего проголосовать:)
Не удалось удалить обработчики событий.
Регистрация для события должна быть сопряжена с un-registering:
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
Существует пример системы, где это произошло на CodeProject.
P/Вызов неуправляемого кода, а не его очистка или не реализация IDisposable, чтобы очистить их.
Не использовать Using.
Отключение связей базы данных.
Неспособность реализовать Dispose и поэтому не удалять дочерние объекты.
Клиентские объекты WCF не работают, как другие объекты IDisposable. Клиент службы WCF должен быть прерван, если операция находится в неисправном состоянии, иначе он будет закрывать соединение. Обычно это усложняется.
Довольно многое при использовании API-интерфейсов Office. Поскольку они все COM-объекты, они должны быть удалены. Вам также необходимо сохранить ссылку на класс, если вы хотите использовать обработчики событий, иначе они потеряют свою ссылку. Во многих случаях вам даже нужно вручную вызвать GC, чтобы очистить объекты
Использование WeakReference может привести к тонкой утечке, когда объект, удерживаемый WeakReference, очищается, потому что у него нет сильных ссылок, но сам WeakReference не потому, что вы держите на нем сильную ссылку.
Вы можете столкнуться с этим, если у вас есть что-то вроде списка или словаря WeakReferences, который вы никогда не обрезаете. Вы закончите утечку объектов WeakReference даже после того, как цель будет собрана.
Не удалось вызвать метод "Закрыть" в объекте System.Windows.Window.
Единственный способ гарантировать, что все управляемые ресурсы для объекта System.Windows.Window собираются с помощью мусора, - это вызов метода Close() для объекта Window. Вызов Dispose или установка ссылки на объект на null не приведет к уничтожению объекта.
Если вы считаете управляемую память как "ресурс" - неспособность отключить обработчики событий, это общий источник утечек памяти (и других других более серьезных ошибок).
Статические списки, словари и ресурсы, основанные на коллекции, которые заполняются вне кода запуска.
Это может произойти, если у вас есть словарь, который вы используете в качестве глобального кеша вместо правильного кеша LRU.
Все, что требуется static, требует большой осторожности!
Простая утечка памяти: создайте статическое поле в классе типа List. Добавить элементы в список. Они никогда не будут собирать мусор, поэтому, если вы не помните, чтобы вручную удалять свои предметы, когда вы с ними закончили, память постоянно привязана.
Руки маркера олицетворения остаются открытыми.
Невозможно удалить любые связанные с чертежом объекты (Graphics, Font, SolidBrush, Pen и т.д.) в .NET Compact Framework. Это может привести к серьезным утечкам памяти, если вы не хотите (мобильное устройство = ограниченная память).
Уязвимость словаря ресурса WPF. Некоторые полезные ссылки:
Невозможно сконфигурировать Spring.NET для создания нескольких экземпляров чего-то, что должно быть одиночным.
Не удалось вызвать Dispose() на Timer