Возможен ли “мусор” в managed типах?

[gecior]

Вопрос на грани философии и практики. Мы все выросли на мантре, что в управляемых средах (CLR/.NET, JVM и т.д.) сборщик мусора (GC) решает все проблемы с памятью. Но действительно ли managed-код гарантирует отсутствие “мусора” в логическом смысле?

GC чистит только то, до чего может дотянуться. Классический мусор в managed-коде это неуправляемые ресурсы без правильного Dispose, вечные статические коллекции, забытые подписки на события и неправильно хранимые ссылки (например, в кэшах или глобальных переменных). Объект может быть живым для сборщика, но абсолютно мёртвым для логики приложения вот он и мусор. Без профайлера (dotMemory, PerfView, встроенного в студию) этот бардак не всегда увидишь, а потом прилетает OutOfMemory или медленная деградация производительности.

Вопросы к сообществу:

С какими скрытыми managed-утечками сталкивались вы? Какие инструменты для диагностики используете (профайлеры, дампы памяти, анализаторы кода)? Есть ли универсальные правила, чтобы избегать такого “мусора”?

Буду рад конструктивному холивару и практическим кейсам.

[Автор]

Записи