Что такое garbage collector и как он работает

Что проверяют

Понимаете ли вы, что автоматическое управление памятью не отменяет утечек, и знаете ли, как они выглядят в Android.

Как отвечать

Сборщик мусора автоматически освобождает объекты, до которых больше нельзя добраться по ссылкам от корней: стеков потоков, статических полей, живых объектов приложения. Работает он по схеме «пометить достижимое, освободить остальное». Ключевой критерий это достижимость, а не «объект больше не нужен по смыслу».

Про Android стоит говорить конкретно про ART:

• сборщик конкурентный и поколенческий: молодые объекты собираются часто и дёшево, долгоживущие реже;
• ART умеет уплотнять кучу, устраняя фрагментацию;
• паузы короткие, но при частых аллокациях в кадре появляются заметные подтормаживания интерфейса, особенно в списках.

Дальше самое ценное: утечка в языке со сборщиком это не «забыли освободить», а «остались лишние ссылки». Типичные источники в Android:

• статическое поле или синглтон, хранящий Context активности;
• внутренний нестатический класс или лямбда, держащая ссылку на Activity, живущая дольше неё;
• незавершённые корутины и не отписанные слушатели, обработчики Handler с отложенными сообщениями;
• подписки RxJava без dispose, наблюдатели без привязки к жизненному циклу.

Отсюда практика: передавать applicationContext там, где не нужен контекст экрана, использовать viewModelScope и lifecycleScope, отписываться в парном методе жизненного цикла, ловить утечки LeakCanary и смотреть Memory Profiler в Android Studio.

Где спотыкаются

Считают, что вызов System.gc() решает проблему. Это подсказка виртуальной машине, а не команда, и на утечку она не влияет.

Путают OutOfMemoryError от утечки и от разовой большой аллокации, например при декодировании крупного изображения.

Не знают про слабые ссылки: WeakReference уместна там, где кеш не должен удерживать объект.