Вайб-код и 14 млн мертвых объектов в куче .NET
Сейчас в индустрии царит опасная эйфория: берем Claude Code или Cursor, скармливаем задачу, за час получаем готовый PR на 5-10 тысяч строк, тесты зелёные - деплоим! Зачем глубоко понимать рантайм, если нейронка "пишет за сеньора"?
Но рантайм .NET и сборщик мусора обмануть нельзя.
Недавно наблюдал классическую картину на живом проекте: Приложение на старте потребляет скромные 220 МБ и держит в памяти около 360 тысяч объектов. Всё летает. Затем оператор просто открывает и закрывает разные экраны интерфейса в течение рабочей смены.
Итог в dotMemory: 1.48 ГБ оперативной памяти и 14.12 МИЛЛИОНОВ живых объектов в куче.
Приложение буквально сжирает доступную память по экспоненте, а операционная система готовится прибить процесс по OOM.
В чем была магия "быстрого кода"?
1. Слепота к жизненному циклу DI: Нейросети обожают генерировать красивые подписки на события через обычный "+=". Но они регулярно забывают про отписку (-=) и контракт IDisposable. Долгоживущий Singleton-сервис под капотом цепко держит ссылку на закрытую ViewModel, превращаясь в неубиваемый GC-Root. Экран закрыт, а в памяти продолжает жить вся его иерархия.
2. Иллюзия вызова GC.Collect(): Первая реакция разработчика без понимания GC это воткнуть ручной вызов сборщика мусора. Но если объект достижим по цепочке ссылок из синглтона, GC.Collect() бессилен. Он только добавляет фризы в UI-потоке.
3. Финал: когда падает сам CoreCLR: Когда поверх этого накладывается работа с нативными хэндлами (IntPtr, графические библиотеки вроде SkiaSharp или драйверы оборудования), наступает худший кошмар - повреждение нативной кучи из-за рассинхрона потоков или double-dispose. Приложение падает с фатальной ошибкой "Fatal error. Internal CLR error. (0x80131506)". Её невозможно отловить через try-catch, в журнале Windows нет стек-трейса, процесс просто мгновенно схлопывается.
ИИ-ассистенты потрясающий инструмент для ускорения рутины, написания DTO и черновиков тестов. Но они фундаментально слепы к графам объектов, конкурентности и аппаратным ограничениям среды.
Писать синтаксис на C# сегодня может даже генеративная модель. А вот понимать, почему этот синтаксис через два часа уронит сервер или промышленный стенд, по-прежнему задача инженера.
Коллеги, сталкивались уже на продакшене с "архитектурными минами", сгенерированными с помощью ИИ? Как отлавливаете подобные утечки на код-ревью до того, как они попадут в продакшен?