Хотите понять, как управляемый язык, такой как C #, имеет утечки памяти

Question

Поскольку C # - это управляемый язык, который выполняет сборку мусора автоматически для очистки объектов и т. Д., ...

как можно вызвать утечку памяти ?

Есть ли какие-то неочевидные способы, которые нужно искать?

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

Answer 1

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

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

Я бы предложил почитать о ГХ и понять, какэто работает.

Вот кое-что, с чего можно начать:

http://www.simple -talk.com / dotnet / .net-framework / понимание-garbage-collection-in-.net/

Answer 2

Утечка памяти означает сохранение в памяти объектов, которые вам больше не нужны.В C #, учитывая, что GC собирает объекты, на которые нет ссылок, это эквивалентно тому, чтобы хранить ссылки на ненужные объекты.Подумайте о неверно ограниченных объявлениях, бесконечной рекурсии или итерации ...

Answer 3

Очевидная «утечка памяти», которую можно вызвать в языке GC-ed, может быть вызвана просто сохранением ссылки на объект после того, как он необходим - это особенно вероятно, если вы свернете свое собственное кэширование или сохраните другое глобальное состояние.

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

(Я отмечаю пост как CW из-за открытого характера вопроса.)

Answer 4

Two.

• Во-первых, создание ссылочных объектов. Как создание объектов, которые подписываются на событие в форме. Форма активна, поэтому не может быть собрана, а подписка на события ... поддерживает объекты живыми.
• Во-вторых, заблокируйте сборщик мусора в нативном коде. Как оракул ODP.NET Driever делает при определенных условиях. Останавливает финализатор, поэтому любой объект, требующий финализации, НЕ ПОЛУЧИТ ЭТОГО - и, следовательно, никогда не будет освобожден.