Имеется очень простенький код:

 

Но при запуске получается сильная утечка памяти в get_new_bitmap() , т.к. он возвращать то возвращает мне Новый объект, однако почему-то сборщик мусора не хочет удалять старый Объект из памяти, который вернул мне в предыдущем вызове
get_new_bitmap(). Можно узнать почему? Как сделать, чтобы  удалялся старый объект?

Добавлено через 9 минут и 19 секунд
Как решить эту проблему я понял, достаточно принудительно заставить сборщик мусора произвести чистку:



Но остаётся вопрос: я всегда думал, что сборщик мусора обязан сам производить чистку в этой ситуации. Почему он этого не делает?
   

У меня все без проблем. 
Попробуй 

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


Это не решение "проблемы", т.к. проблемы нет. Это, наоборот, потенциальное добавление проблем. Вызывать GC ручками нужно только в крайних случаях, например, при работе с COM объектами.

Есть очень хорошее правило, при работе с управляемой памятью: "выделил и забыл".

Читаем про IDisposable и оператор using.

Тоже столкнулся с утечкой памяти, имею в чужом, большом проекте такую конструкцию:



Проблема в том, что старый obj остается в памяти, несмотря на обнуление ссылки на него. Вообще проблема была обнаружена т.к. obj не "отписывался" от событий, на которые подписан и продолжал делать свою работу вместе с новым экземпляром. Я то конечно отписал его от событий, пользователь косяков больше не видит, но после небольшого теста - запуска цикла всего лишь с 10 save'ми - свободной памяти стало на 230мб меньше    Погуглив, решил что лучшее решение - реализовать метод Dispose(). Но! Надо сказать obj - очень сложный, большой объект, который включает в себя много других больших, сложных объектов, которые... и так далее. Таких классов порядка 500. Значит, для каждого надо реализовать Dispose(). Что делать мягко говоря не хочется, по крайней мере пока, т.к. только начинаю разбираться с проектом.

есть ли способ удалить obj попроще, не переписывая весь проект?

для спокойствия моей совести было бы достаточно, если бы сборщик мусора когда-нибудь очистил память, только сдается мне никогда этого не случится
простенький пример, как мне кажется аналогичный моему случаю :


При втором варианте - формы плодятся, старые не исчезают, я наивно полагал что все ссылки на форму удалил и она удалится сборщиком мусора. Почему не удаляется? И что надо сделать чтобы сборщик мусора ее удалил сам (без помощи Dispose).

Ещё один вопрос родился: можно ли получить все ссылки на заданный объект? Может в процессе отладки можно?

Это сообщение отредактировал(а) МастерФломастер - 11.4.2011, 16:36

Если ссылки обнулены то никакой утечки не будет. для потенциально больших обьектов типа Bitmap сделан Dispose

Это сообщение отредактировал(а) bend0r - 11.4.2011, 14:50

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

И прокомментируйте, пожалуйста, пример с формами, там вот тоже ссылка вроде как обнуляется, а толку нет.

Это сообщение отредактировал(а) МастерФломастер - 11.4.2011, 16:34

Kомпилятор оптимизирует твой код и просто выкидывает f=null;
Попробуй написать f.Dispose. Или как-нибудь использовать f:

f=null;
if (f!=null) Console.Write("Something fucked up definitely!");

уфффф


f=null;
if (f!=null)  - не выполнится никогда!

ссылка обнуляется, ниче компилятор не выкидывает!  Вы запустите пример у себя. Сначала первый вариант, затем второй. Почуствуйте разницу! с каждым кликом появляется новая форма, a старые остаются.

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

ну так реализуй его, он определен в интерфейсе IDisposeble, наследуй и пиши.

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

самой кривейший вариант. Если бы у меня на проекте кто ниб вызовет GC сам - тут же уволю нахрен. (Естественно ситуации возможны разные, но надо настолько обосновать, что проще плюнуть и не писать))) Я за свою жисть ни разу не встречал необходимости ручного сбора мусора, а вот заметок типа "не трогайте этот рычаг" очень много где видел, в том числе и в так излюбленном всеми Рихтере.

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

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