Чтобы добавить немного ответа Брайана и ваш комментарий / вопрос:
Разница между управляемым / неуправляемым ресурсом заключается в том, что сборщик мусора знает об управляемых ресурсах и не знает о неуправляемых ресурсах. Я знаю, что ответ не очень конкретен, но разница огромна.
Чтобы помочь провести черту в песке, вот краткая (и, вероятно, пронизанная мелкими ошибками) версия того, как GC работает и очищает память:
Сборщик мусора знает обо всех управляемых объектах, но когда запускается сборщик мусора, он изначально не знает, используется ли какой-либо данный объект или еще может быть освобожден. Он определяет, может ли он очистить объект, сначала пометив все объекты как мусор, а затем пройдя путь от корня приложения ко всем ссылочным объектам. Каждый объект, имеющий отношение к корню (прямая или косвенная ссылка), помечается как достижимый и больше не считается мусором. После того, как GC проходит через каждый достижимый объект, он очищает остальные, так как они больше не используются.
Практически во всех случаях, работая с объектами .NET Framework, вы можете быть уверены, что объекты управляются (.NET предоставляет управляемые оболочки почти всех неуправляемых ресурсов для обеспечения их надлежащей очистки); другие сторонние компоненты, которые подключаются к Win32 API (или ваши компоненты, которые делают это), являются объектами, которые могут вызывать беспокойство.
Существуют некоторые объекты .NET, которые можно считать неуправляемыми. Компоненты графической библиотеки являются одним из примеров.
Большинство «утечек памяти .NET» в действительности не являются утечками памяти. Обычно они происходят, когда вы думаете, вы удалили объект из использования, но на самом деле объект все еще имеет некоторую ссылку на приложение. Типичным примером является добавление обработчиков событий (obj.SomeEvent + = OnSomeEvent -or- AddHandler obj.SomeEvent, AddressOf OnSomeEvent), а не их удаление.
Эти «давние ссылки» технически не являются утечками памяти, поскольку ваше приложение все еще технически их использует; однако, если их достаточно, ваше приложение может испытать серьезное влияние на производительность и может показать признаки проблем с ресурсами (OutOfMemoryExceptions, невозможность получить дескрипторы окна и т. д.).
Я являюсь промежуточным разработчиком .NET и, к сожалению, знаю об этих проблемах из первых рук. Я рекомендую поиграть с ANTS Profiler, чтобы познакомиться с давними ссылками (есть бесплатная пробная версия) или если вы хотите получить немного больше подробных исследований, используя WinDbg и SOS.DLL, чтобы посмотреть на управляемую кучу. Если вы решите взглянуть на последнее, я рекомендую прочитать блог Тесс Феррандез; у нее много отличных уроков и советов по эффективному использованию Windbg