Утечка ресурсов .NET Gotchas
Чтобы исключить исключительное исключение индекса массива, следует использовать инструкцию расширенный- for , где и когда они могут.
Основная мотивация (и использовать), когда вы выполняете итерацию, и вам не требуются сложные шаги итерации. Вы не могли бы использовать расширенный for для перемещения назад в массиве или только для итерации на каждом другом элементе.
Вы гарантированно не исчерпали элементы для повторения при этом, а ваш [исправленный] пример легко конвертируется.
Код ниже:
String[] name = {"tom", "dick", "harry"};
for(int i = 0; i< name.length; i++) {
System.out.print(name[i] + "\n");
}
... эквивалентен этому:
String[] name = {"tom", "dick", "harry"};
for(String firstName : name) {
System.out.println(firstName + "\n");
}
16 ответов
Ошибка при удалении обработчиков событий.
Регистрация события должна сопровождаться отменой регистрации:
this.myObject.MyEvent += new EventHandler(myObject_MyEvent);
this.myObject.MyEvent -= new EventHandler(myObject_MyEvent);
Существует пример системы, в которой это произошло на CodeProject .
Неспособность удалить какие-либо объекты, связанные с Рисунком (Graphics, Font, SolidBrush, Pen, и т. д.) ) в .NET Compact Framework. Это может вызвать серьезные утечки памяти, если вы этого не хотите (мобильное устройство = ограниченная память).
Статические списки, словари и ресурсы на основе коллекций, которые заполняются вне кода запуска.
Это может произойти, если у вас есть словарь, который вы используете в качестве глобального кэша, вместо правильного кеша на основе LRU.
Все статические требуют особой осторожности!
Сбой при вызове метода Close для объекта System.Windows.Window.
Единственный способ гарантировать, что все управляемые ресурсы для объекта System.Windows.Window собираются сборщиком мусора заключается в вызове метода Close () объекта Window. Вызов Dispose или установка для ссылки на объект значения null не приведет к уничтожению объекта.
Если вы считаете управляемую память как «ресурс», то обычно не удается отсоединить обработчики событий. утечки памяти (и другие более серьезные ошибки).
Использование WeakReference может привести к неуловимой утечке, когда объект, удерживаемый WeakReference, очищается, потому что у него нет сильных ссылок, но сама WeakReference - не потому, что вы сохраняете на него сильную ссылку.
Вы можете столкнуться с этим, если у вас есть что-то вроде List или Dictionary of WeakReferences, которые вы никогда не сокращаете. Вы закончите утечку объектов WeakReference даже после того, как цель будет собрана.
Практически все, что угодно при использовании API Office. Поскольку все они являются объектами COM, их необходимо удалить. Вы также должны сохранить ссылку на класс для них, если вы хотите использовать обработчики событий, иначе они потеряют свою ссылку. Во многих случаях вам даже придется вручную вызывать сборщик мусора, чтобы очистить объекты
Клиентские объекты WCF не работают так, как другие объекты IDisposable. Клиент службы WCF должен быть прерван, если операция находится в состоянии сбоя, иначе соединение будет оставаться открытым. Обычно этому учатся на горьком опыте.
Для членов класса POD это не имеет значения, это просто вопрос стиля. Для членов класса, которые являются классами, это позволяет избежать ненужного вызова конструктора по умолчанию. Рассмотрим:
class A
{
public:
A() { x = 0; }
A(int x_) { x = x_; }
int x;
};
class B
{
public:
B()
{
a.x = 3;
}
private:
A a;
};
В этом случае конструктор для B вызовет конструктор по умолчанию для A , а затем инициализирует ax значением 3. Лучше бы быть для конструктора B для прямого вызова конструктора A в списке инициализаторов:
B()
: a(3)
{
}
Это вызовет только A A (int) конструктор, а не его конструктор по умолчанию. В этом примере разница незначительна, но представьте, если хотите, что конструктор по умолчанию A сделал больше, например выделил память или открывал файлы. Ты бы не стал
Простая утечка памяти: создайте статическое поле в классе типа List. Добавить элементы в список. Они никогда не будут собирать мусор, поэтому, если вы не забудете вручную удалить свои элементы, когда закончите с ними, память будет постоянно заблокирована.
P / Вызов неуправляемого кода без его очистки или без реализации IDisposable для их очистки.
Misconfiguring Spring.NET to create multiple instances of something that should be a singleton.