Garbage Collector

Каковы основные принципы работы механизма сборки мусора `(garbage collector)`?

В Kotlin/JVM сборкой мусора управляет JVM. На Android эту роль выполняет ART, а Kotlin/Native использует собственный сборщик. Ниже описаны общие принципы и особенности JVM.

Отслеживание ссылок: Механизм сборки мусора отслеживает ссылки на объекты в программе. Объекты, на которые нет ссылок из корневого множества, считаются недостижимыми и могут быть удалены.
Маркировка-удаление: Процесс сборки мусора включает этап маркировки, где все достижимые объекты помечаются, а затем удаляются недостижимые объекты.
Оптимизации: JVM может использовать различные оптимизации для улучшения производительности сборки мусора, такие как параллельная или инкрементальная сборка, а также различные алгоритмы сборки мусора в зависимости от сценария использования приложения.
Явный запрос: System.gc() просит JVM выполнить сборку мусора, но не гарантирует её запуск или освобождение нужного объёма памяти.

Какие существуют типы ссылок в механизме сборки мусора `(garbage collector)`?

В механизме сборки мусора существуют следующие типы ссылок:

Strong References: Объект сохраняется, пока достижим от корней GC по цепочке сильных ссылок. Недостижимый цикл сильных ссылок может быть собран.
Weak References: Не удерживают объект, если он больше не достижим через сильные или мягкие ссылки. Сборщик очищает слабые ссылки при обнаружении слабой достижимости.
Soft References: Сборщик может очистить мягкие ссылки по своей политике. Все мягкие ссылки на мягко достижимые объекты очищаются перед OutOfMemoryError, но очистка возможна и раньше.
Phantom References: Позволяют через ReferenceQueue отслеживать фантомную достижимость для очистки внешних ресурсов. get() всегда возвращает null; уведомление не подтверждает, что память объекта уже освобождена.

Какие типы ссылок существуют в механизме сборки мусора `(garbage collector)`, включая сильные, слабые, мягкие и фантомные ссылки?

В механизме сборки мусора существуют четыре типа ссылок:

Strong References: Объект сохраняется, пока достижим от корней GC по цепочке сильных ссылок. Недостижимый цикл сильных ссылок может быть собран.
Weak References: Не удерживают объект, если он больше не достижим через сильные или мягкие ссылки. Сборщик очищает слабые ссылки при обнаружении слабой достижимости.
Soft References: Сборщик может очистить мягкие ссылки по своей политике. Все мягкие ссылки на мягко достижимые объекты очищаются перед OutOfMemoryError, но очистка возможна и раньше.
Phantom References: Позволяют через ReferenceQueue отслеживать фантомную достижимость для очистки внешних ресурсов. get() всегда возвращает null; уведомление не подтверждает, что память объекта уже освобождена.

С какими типами ссылок вы работали в механизме сборки мусора `(garbage collector)`?

Основные типы ссылок в механизме сборки мусора:

Strong References (сильные ссылки): Используются по умолчанию в большинстве случаев. Обычно это обычные ссылки на объекты.
Weak References (слабые ссылки): Часто используются для реализации кэшей или связанных со слабой ссылкой структур данных.
Soft References (мягкие ссылки): Используются для кэширования данных, которые можно удалить из памяти, если нет необходимости.
Phantom References: Позволяют через ReferenceQueue отслеживать фантомную достижимость для очистки внешних ресурсов. get() всегда возвращает null; уведомление не подтверждает, что память объекта уже освобождена.

Как работает сборщик мусора в Kotlin и чем он отличается от сборщика мусора в Java?

Kotlin/JVM и Java используют сборщик одной и той же JVM. Он освобождает память недостижимых объектов. Если ненужный объект остаётся достижимым, утечка памяти возможна и при наличии GC.

При запуске на одной JVM различий в механизме GC из-за языка нет. Это сравнение не распространяется на Kotlin/Native и другие целевые платформы Kotlin.

Какие типы объектов не могут быть собраны сборщиком мусора?

GC не собирает объекты, сильно достижимые от корней GC. Статическое поле может удерживать объект, пока сохраняется соответствующая достижимость; само наличие ссылок внутри недостижимой группы объектов не мешает сборке.

Объясните понятие `"stop-the-world"` в контексте сборки мусора.

Stop-the-world, или STW, означает приостановку потоков приложения в данной JVM на время определённой фазы GC. Другие JVM и приложения системы не останавливаются. Конкурентные сборщики выполняют часть работы одновременно с приложением, но также могут иметь STW-фазы.

Какие методы существуют для принудительной сборки мусора и когда их следует использовать?

В Kotlin/JVM и Java System.gc() отправляет запрос на сборку мусора. JVM не обязана выполнять его немедленно или освобождать конкретные объекты. Такой вызов не подходит для гарантированного освобождения памяти или внешних ресурсов; для ресурсов используют явное закрытие.