Как избежать Утечек памяти? [закрытый]

Используйте ключевое слово «using» для автоматического вызова метода Dispose () объекта IDisposable.
Для любого взаимодействия COM вы должны вручную освободить все ресурсы.

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

Сказав это, можно получить более слабое понимание того, что такое утечка памяти. Если вы считаете утечку памяти неконтролируемым ростом используемой памяти, это очень просто. Просто сделайте большое неправильное использование статических переменных, в основном тех, которые ссылаются на огромные списки. Если вы сохраните ссылки на эти объекты, GC никогда не очистит их, продвигая их к более высоким поколениям и делая их еще труднее собирать. Даже если это не утечка памяти в строгом смысле этого слова, в конечном итоге это может привести к аналогичным симптомам. Хороший способ попытаться обнаружить такую ​​утечку - использовать CLR Profiler .

Другим источником «утечек» является неправильное использование обработчиков событий, как указано ранее. Каждый раз, когда этот объект A регистрирует один из своих методов экземпляра с событием в объекте B, объект B прекращает сохранять косвенную ссылку на объект A, что означает, что, пока B жив, A будет поддерживаться живым. Обратите внимание, однако, что здесь нет округлости. Как только ни B, ни A не имеют какой-либо корневой ссылки, независимо от того, сколько перекрестных ссылок у них есть, они в конечном итоге будут собраны.

Наконец, можно фактически вызвать утечку памяти в .net, но никогда (по крайней мере, теоретически), когда речь идет об управляемой памяти, поскольку GC отлично справляется с этой задачей. Если какой-либо из ваших объектов поддерживает ссылку на неуправляемую память, например, посредством взаимодействия, то эту память необходимо явно очистить. Несоблюдение этого требования может привести к утечке памяти. Хотя я никогда не сталкивался с таким сценарием, по крайней мере, теоретически это может произойти Как указывалось ранее, объекты, которые содержат такие ссылки, должны реализовывать IDiposable для того, чтобы очистить память и их использование должно гарантировать, что Dispose вызывается для этой цели, главным образом, с помощью предложения using. Обратите внимание, что Dispose не освободит память объекта, а только попросит объект освободить любую неуправляемую память, на которую он ссылается.

Один особый вид неуправляемой памяти - это тот, который необходим COM-объектам, используемым в сценариях взаимодействия. Эти объекты доступны через Runtime Callable Wrappers, RCW для друзей, но не имеют утилизации. «Использование» не будет работать. Способ освобождения базовых COM-объектов - через статический метод:

System.Runtime.InteropServices.Marshal.ReleaseComObject(object);

Так как «использование» является только синтаксическим сахаром для вызова IDisposable.Dispose () в блоке finally, его нельзя использовать с RCW, поэтому не забудьте поместите вызов в ReleaseComObject (object) в блок finally, чтобы убедиться, что он действительно вызывается.

Это управляемый код, это c #, так что вам нужно изо всех сил пытаться утечь память: P

Попробуйте Google: http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=Mbp&q=c%23+memory+leaks&btnG=Search

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

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

Как уже говорили другие, вызовите Dispose () (или используйте оператор using), но дополнительно подумайте, используют ли классы ресурсы и, если это так, реализуют IDisposeable. Чаще всего проблема в моем коде заключается в том, что у меня есть класс с членом, который не очищается до GC.

Наиболее распространенный случай, когда память не уничтожается ГХ, - это когда у вас есть обработчики событий, которые не были отцеплены должным образом. Вы можете отцепиться в Dispose (), если хотите.

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

Большинство утечек памяти, с которыми я столкнулся в .NET, связано с использованием объектов COM и их неправильным освобождением. Как только я вижу ссылку на COM-объект, я думаю, что "утечка памяти".

Общее представление о том, как работает сборщик мусора , поможет вам избежать злоупотребления памятью. Например, если вы сохраняете ссылку на объект, который вам больше не нужен, gc не сможет его собрать.

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

Я столкнулся с проблемами, когда объект (Ping) дважды реализовал Dispose (), реализовав интерфейс IDisposable и унаследовав его одновременно. Унаследованный метод ничего не делал, и в результате вы должны были привести объект к IDisposable при вызове Dispose (), иначе это приведет к утечке памяти. Вот пост , который я написал несколько лет назад с более подробной информацией.

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

Я знаю, что некоторые люди посоветуют сборку мусора в качестве решения. Но во многих случаях сборка мусора не дает ожидаемых результатов. Легко в конечном итоге держаться за ложную ссылку, которая препятствует освобождению целых цепочек памяти. Прочитайте о том, как это торпедировало запись DARPA Grand Challenge. Вы можете утверждать, что это не утечки памяти, но если программа ожидает освобождения памяти, это все еще проблема. Как и в программировании на C, через пару месяцев вы научитесь следить за тем, чтобы не оставлять нежелательные ссылки.

1. Обернуть все, что можно использовать в конструкции с использованием.
2. Избегать объектов COM.
3. Проверить, что все обработчики событий удаляются правильно.
4. Проверить, чтобы все привязки данных удаляются должным образом.
5. Сохраняйте это простым

Если логика вашего приложения становится излишне сложной, вы можете столкнуться с утечками памяти. Если вы сохраняете свои классы небольшими и придерживаетесь общих правил кодирования, вы, вероятно, не столкнетесь с утечками памяти при использовании управляемого кода. Это возможно, но не так вероятно, как раньше.

Если вы подозреваете утечку памяти, используйте профилировщик, чтобы увидеть, хранятся ли какие-либо объекты дольше, чем нужно.

В последний раз, когда я столкнулся с серьезной утечкой памяти, был .NET 1.1, оказалось, что ошибка в рамках.

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

Начните с заботы о качестве разработанного кода и следуя рекомендациям, упомянутым другими.

1. Простота золотой - чем проще код - тем меньше вероятность ошибок или утечек
2. Будьте осторожны при использовании неуправляемых ресурсов - дескрипторов Windows, соединений с БД, объектов GDI и т. д.
3. Используйте использование для IDisposables
4. Реализация IDisposable для классов, которые несут неуправляемые ресурсы
5. Убедитесь, что удалили все ссылки на неиспользуемые объекты - включая сложные обработчики событий

Вдобавок к этому - реализуют тесты , чтобы видеть, утечки памяти - единица измерения, тесты на параллелизм, стресс и нагрузку могут помочь здесь больше всего. Смотрите, если утечки памяти, проверяя метрики (счетчики перфорации). Вы также можете регистрировать создание и разрушение объектов и анализировать журналы в конце теста.

Как уже упоминалось в ocdecio, обязательно вызовите Dispose для объектов Idisposable и не забудьте удалить обработчики событий, когда вы закончите с объектом. При создании классов, которые работают с неуправляемыми ресурсами, обязательно реализуйте Idisposable, чтобы пользователь знал, что существуют критически важные ресурсы, которые нужно будет утилизировать.

Кроме того, даже если сборка мусора довольно трудоемка для вы, вы должны избавиться от ссылок на объекты, которые вы сделали. Иначе у них все еще будет рут, и они не будут GC'ed.

Не стоит недооценивать полезность инструментов в этих ситуациях. Профилировщики памяти .NET в настоящее время достаточно развиты и надежны, и если у вас есть сложное приложение, в котором объект, который, по вашему мнению, должен быть освобожден, по-прежнему удерживается в качестве ссылки, то есть возможность точно определить эту ссылку неоценима.

I Вы только что закончили поиск утечки памяти, когда на вкладке WPF размещался элемент управления Windows Form (поскольку на этих вкладках было много данных, и вы могли открывать и закрывать их по своему желанию, просто ожидая, пока GC не очистит память при закрытии, не было опция). Я использовал профилировщик YourKit , чтобы сделать снимок памяти перед открытием вкладки, открыл вкладку, снова закрыл ее и сделал еще один снимок. Внутри профилировщика вы можете визуально сравнить два снимка и увидеть, какие объекты пережили процесс, и проследить их ссылки на корень GC. У меня нет опыта работы с другими профилировщиками, но я знаю, что есть некоторые из них, если YourKit не удовлетворяет вашим потребностям.

---

Отредактировано, чтобы добавить:

Хорошо, это не избегает памяти утечки, это их исправление. Но я оставлю это здесь, так как считаю, что это полезная информация, и я не думаю, что разработчики .NET знают об этих инструментах достаточно.

Внутри профилировщика вы можете визуально сравнить два снимка и увидеть, какие объекты пережили процесс, и проследить их ссылки на корень GC. У меня нет опыта работы с другими профилировщиками, но я знаю, что есть некоторые из них, если YourKit не удовлетворяет вашим потребностям.

---

Отредактировано, чтобы добавить:

Хорошо, это не избегает памяти утечки, это их исправление. Но я оставлю это здесь, так как считаю, что это полезная информация, и я не думаю, что разработчики .NET знают об этих инструментах достаточно.

Внутри профилировщика вы можете визуально сравнить два снимка и увидеть, какие объекты пережили процесс, и проследить их ссылки на корень GC. У меня нет опыта работы с другими профилировщиками, но я знаю, что есть некоторые из них, если YourKit не удовлетворяет вашим потребностям.

---

Отредактировано, чтобы добавить:

Хорошо, это не избегает памяти утечки, это их исправление. Но я оставлю это здесь, так как считаю, что это полезная информация, и я не думаю, что разработчики .NET знают об этих инструментах достаточно.

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

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

Моя новая статья может оказаться полезной: Как обнаружить и избежать утечек памяти и ресурсов в приложениях .NET