--- title: Garbage Collector seo: title: Garbage Collector — Kotlin Developer description: Тема «Garbage Collector» для собеседования Kotlin Developer. Каковы основные принципы работы механизма сборки мусора (garbage collector)? Какие существуют типы ссылок в механизме сборки мусора (garbage collector)? --- [Все темы Kotlin Developer](/kotlin-developer) ## Каковы основные принципы работы механизма сборки мусора (garbage collector)? [#q-14bee738d69b8117a70ad871ee8451e4] В Kotlin/JVM сборкой мусора управляет JVM. На Android эту роль выполняет ART, а Kotlin/Native использует собственный сборщик. Ниже описаны общие принципы и особенности JVM. 1. Отслеживание ссылок: Механизм сборки мусора отслеживает ссылки на объекты в программе. Объекты, на которые нет ссылок из корневого множества, считаются недостижимыми и могут быть удалены. 1. Маркировка-удаление: Процесс сборки мусора включает этап маркировки, где все достижимые объекты помечаются, а затем удаляются недостижимые объекты. 1. Оптимизации: JVM может использовать различные оптимизации для улучшения производительности сборки мусора, такие как параллельная или инкрементальная сборка, а также различные алгоритмы сборки мусора в зависимости от сценария использования приложения. 1. Явный запрос: System.gc() просит JVM выполнить сборку мусора, но не гарантирует её запуск или освобождение нужного объёма памяти. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## Какие существуют типы ссылок в механизме сборки мусора (garbage collector)? [#q-14bee738d69b8181bba2dea6561f0c74] В механизме сборки мусора существуют следующие типы ссылок: 1. Strong References: Объект сохраняется, пока достижим от корней GC по цепочке сильных ссылок. Недостижимый цикл сильных ссылок может быть собран. 1. Weak References: Не удерживают объект, если он больше не достижим через сильные или мягкие ссылки. Сборщик очищает слабые ссылки при обнаружении слабой достижимости. 1. Soft References: Сборщик может очистить мягкие ссылки по своей политике. Все мягкие ссылки на мягко достижимые объекты очищаются перед OutOfMemoryError, но очистка возможна и раньше. 1. Phantom References: Позволяют через ReferenceQueue отслеживать фантомную достижимость для очистки внешних ресурсов. get() всегда возвращает null; уведомление не подтверждает, что память объекта уже освобождена. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## Какие типы ссылок существуют в механизме сборки мусора (garbage collector), включая сильные, слабые, мягкие и фантомные ссылки? [#q-14bee738d69b817bb924f11d3a33baed] В механизме сборки мусора существуют четыре типа ссылок: 1. Strong References: Объект сохраняется, пока достижим от корней GC по цепочке сильных ссылок. Недостижимый цикл сильных ссылок может быть собран. 1. Weak References: Не удерживают объект, если он больше не достижим через сильные или мягкие ссылки. Сборщик очищает слабые ссылки при обнаружении слабой достижимости. 1. Soft References: Сборщик может очистить мягкие ссылки по своей политике. Все мягкие ссылки на мягко достижимые объекты очищаются перед OutOfMemoryError, но очистка возможна и раньше. 1. Phantom References: Позволяют через ReferenceQueue отслеживать фантомную достижимость для очистки внешних ресурсов. get() всегда возвращает null; уведомление не подтверждает, что память объекта уже освобождена. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## С какими типами ссылок вы работали в механизме сборки мусора (garbage collector)? [#q-14bee738d69b81b7901edd0175bb3389] Основные типы ссылок в механизме сборки мусора: 1. Strong References (сильные ссылки): Используются по умолчанию в большинстве случаев. Обычно это обычные ссылки на объекты. 1. Weak References (слабые ссылки): Часто используются для реализации кэшей или связанных со слабой ссылкой структур данных. 1. Soft References (мягкие ссылки): Используются для кэширования данных, которые можно удалить из памяти, если нет необходимости. 1. Phantom References: Позволяют через ReferenceQueue отслеживать фантомную достижимость для очистки внешних ресурсов. get() всегда возвращает null; уведомление не подтверждает, что память объекта уже освобождена. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## Как работает сборщик мусора в Kotlin и чем он отличается от сборщика мусора в Java? [#q-14bee738d69b81b0a820cb7a358daf04] Kotlin/JVM и Java используют сборщик одной и той же JVM. Он освобождает память недостижимых объектов. Если ненужный объект остаётся достижимым, утечка памяти возможна и при наличии GC. При запуске на одной JVM различий в механизме GC из-за языка нет. Это сравнение не распространяется на Kotlin/Native и другие целевые платформы Kotlin. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## Какие типы объектов не могут быть собраны сборщиком мусора? [#q-14bee738d69b8142a235d609e0b05ee2] GC не собирает объекты, сильно достижимые от корней GC. Статическое поле может удерживать объект, пока сохраняется соответствующая достижимость; само наличие ссылок внутри недостижимой группы объектов не мешает сборке. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## Объясните понятие "stop-the-world" в контексте сборки мусора. [#q-14bee738d69b8142be9df4b32ed6b1ec] Stop-the-world, или STW, означает приостановку потоков приложения в данной JVM на время определённой фазы GC. Другие JVM и приложения системы не останавливаются. Конкурентные сборщики выполняют часть работы одновременно с приложением, но также могут иметь STW-фазы. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) ::: --- ## Какие методы существуют для принудительной сборки мусора и когда их следует использовать? [#q-14bee738d69b81ae955bf48504ddabb2] В Kotlin/JVM и Java System.gc() отправляет запрос на сборку мусора. JVM не обязана выполнять его немедленно или освобождать конкретные объекты. Такой вызов не подходит для гарантированного освобождения памяти или внешних ресурсов; для ресурсов используют явное закрытие. :::note[Ссылки для изучения] 1. [Работа с памятью в Kotlin](https://kmm.icerock.dev/learning/memory_management) :::