А бывают ли в Си# утечки памяти? Зачем нужен IDisposable? Часто ли он встречается? Если забыть Dispose, что будет? Как проконтролировать?

Конечно утечки бывают...бажный код -> висячие ссылки на объекты -> сборщик мусора не убивает их...в итоге получаем утечку...

А насчёт IDisposable в MSDN всё предельно ясно написано...



Вопроса "Часто ли он встречается" я вообще не понял...вы о чём?

Ответ на последние два вопроса лежит в приведённой выше цитате из MSDN

Dims, еще можно добавить невыгружаемые генерируемые сборки и утечки дескрипторов.
Частота встречания зависит от опыта. Например, у класса XmlSerializer 9 конструкторов, из них 7 сильно текут. Это описано в документации, но кто ее читает...

Это как? Можно поподробнее?


Я не врубаюсь. Является ли это обязательным или это просто желательно?


Тоже, если можно, поподробнее 

Dims, 



Обязательным это не является. Использовать IDisposable необходимо, если ваш класс занимает unmanaged-ресурсы и при удалении объекта их необходимо освобождать. GС при удалении объекта IDisposable обязательно вызовет Dispose.



Ну, допустим у вас есть класс-коллекция с собственной имплементацией добавления / удаления объектов...
Допустим реализация удаления немного бажная....и иногда объект из коллекции не удаляется, а новые объекты  всё так же добавляются...
В результате объекты, которые по сути нигде не используются остаются торчать в коллекции и GC их на тот свет никак не хочет забирать...
В итоге получаем о-го-гошное отжирание памяти...

Пример немного надуман, но общий смысл проблемы с "висящими ссылками", думаю, передаёт.

LeakSample1 каждый раз создает динамическую сборку и не выгружает ее. И к тому же тормозит. Причины и последствия описаны в документации. 
LeakSample2 закрепляет объект в памяти перед передачей неуправляемому коду. И забывает открепить - не обязательно намеренно, может быть просто из-за исключения в неуправляемом коде. В результате в памяти образуется кусок, который GC не может освободить, и который ему приходится обходить при сборке мусора.

Но чаще всего утечки - это просто висящие ссылки, часто неявные. Например, нестатические обработчики событий и callback-и. Но такие случаи можно отловить профайлером.

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



Кстати, а что используется в качестве профайлера?

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

Есть более удачный пример...






.NET Profiler

memprofiler.com и стандартный sos.

Весь бонус сборщика мусора в том, что он сам знает какие объекты нужны. Возьми рихтера, там подробно расписан процесс.

Dims, про память в дотнет на основе сборки мусора и поколений отлично у Джеффри Рихтера в книге расписано.  

Утечек в pure MSIL не быввает.
Бывают ошибки, когда уже ненужные переменные "как будто нужны и используются", но это уже ошибки проектирования.

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

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

nerezus, 




Переменная t ссылается на новый объект, старый объект остался...

nerezus, в примере LeakSample2 выше ссылки на управляемый объект objectToPin уже нет, но он остается в оперативке и GC его обходит стороной. Есть только отметка "этот кусок памяти занят" - ну так она и в unmanaged коде есть. Это тоже утечка. В чистом MSIL.

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

Старый поток вместе со старым объектом Thread подгребётся на следующей же сборке мусора   

банальность:
вызовите метод Close() в обработчике OnLoad у формы - получите утечку)

mr.DUDA, как старый поток подгребётся, если он ещё выполняется?