Garbage Collector в Java. Reference Counting. Часть 3.1.

Reference Counting – данный подход основан на подсчете ссылок, о чем можно догадаться из названия.

Суть подхода состоит в том, что каждый объект имеет некоторый счетчик. Этот счетчик хранит информацию о том, сколько ссылок указывает на объект. Kогда какая-либо ссылка уничтожается, то и значение счетчика уменьшается.

Если значение счетчика равно нулю – объект можно считать мусором и память, которую он занимает, можно очищать.
Как это выглядит, можно посмотреть на картинке.

Из плюсов данного подхода можно выделить несколько: простота, не требуются долгие паузы для сборки мусора.

Однако, есть и существенные минусы:

– Плохо сочетается с многопоточностью;

– Сложно выявлять циклические зависимости;

– Влияет на производительность – каждый раз, когда мы что-то читаем, записываем ссылку на объект в локальную переменную, нам нужно увеличивать счетчик.

Благодаря своим минусам данный подход не используется и вытеснен более гибким подходом, под названием Tracing.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Garbage Collector в Java. Reference Counting. Часть 3.2.

Одним из минусов подхода Reference Counting является сложность выявления циклических зависимостей.

Циклические зависимости – когда два объекта указывают друг на друга, но ни одна ссылка из Stack на них не ссылается. Это приводит к утечкам памяти. Наглядно можно посмотреть на картинке – каждый из объектов на рисунке имеет по одной ссылке на себя, однако только один является по-настоящему "живым" и нужным.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Garbage Collector в Java. Tracing, GC Root. Часть 4.2.

На собеседованиях Java–разработчиков и стажеров часто спрашивают о том, какие бывают GC Root?

Как мы уже поняли из предыдущего поста с примером c Person – локальные переменные являются GC Root.

Компилятор вычисляет для всех переменных live ranges – это всё, что находится на любых путях исполнения от определения переменной до последнего использования (или использований, они могут быть разные на разных путях).

Другими словами, компилятор всегда знает: жива сейчас переменная или нет, могут ее потенциально в будущем еще использовать или нет.

GC тоже ориентируется на это знание от компилятора. Если переменная вне своего live range, то значит она уже не будет корнем.

Но что еще может быть корневой точкой?

Корневой точкой могут быть:

– Локальные переменные и параметры методов;

– Потоки Java;

– Статические переменные;

– Ссылки из JNI.

Из этого следует, что даже самое простое java приложение имеет следующие GC Root:

– Локальные переменные внутри main метода;

– Статические переменные класса, содержащего main метод;

– Параметры main метода;

– Поток, который выполняет main метод.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Не стоит доверять чатуГПТ на 100%. Доверяй, но проверяй 🧑‍💻

✅ JavaStart. Подписаться

Garbage Collector в Java. Часть 5.1. Алгоритмы очистки памяти. Copying collectors.

Очистка памяти процесс довольно сложный, поэтому было также разработано несколько алгоритмов, выполняющих эту задачу.

Рассмотрим Copying collectors.

Память условно делится на две области: from–space и to–space.
Все объекты создаются в области from–space, по мере заполнения этой области запускается очистка мусора. Приложение полностью останавливается – происходит так называемый stop–the–world – в момент начала очистки, после чего все "живые" объекты в from–space копируются в to–space.
После того, как все "живые" объекты скопированы происходит полная очистка from–space и области меняются местами.

Stop–the–World – это остановка любой мутирующей heap активности.

Из плюсов можно выделить то, что объекты плотно забивают память, поэтому tracing происходит быстрее.

Из минусов можно отметить полную остановку приложения и то, что у нас одна область памяти, по сути, не используется, а при большом количестве объектов это проблема.

Для тех приложений, где пауза критична существует такое понятие как инкрементальная сборка. Там мы делаем большое количество кратковременных пауз. Это выражается в большей нагрузке на приложение.

Примером инкрементального сборщика может являться CMS GC.
Перечисленные минусы довольно весомые, поэтому сейчас данный алгоритм практически не используется.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

Garbage Collector в Java. Часть 5.3. Алгоритмы очистки памяти. Mark–and–Sweep Compact.

В отличии от простого Mark–and–sweep мы ищем "мертвые" объекты, помечаем их для переноса и только после этого останавливаем приложение для очистки памяти.

Так как с "мертвыми" объектами наше приложение уже не работает, мы можем искать их параллельно работе приложения. Это очень эффективно, так как мы теперь не тратим время паузы на поиск, как в предыдущих алгоритмах.

После завершения процедуры удаления происходит compact – мы дефрагментируем память. Объекты "сдвигаются" на более близкие адреса.

Плюсы:

– Нет фрагментации памяти;

– Эффективная работа при большом количестве "живых" объектов.

Минусы:

– Плохо работает при большом количестве "мертвых" объектов;

– Compact – дорогостояющая операция, занимающая много времени.

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться

✅ JavaStart. Подписаться

Garbage Collector в Java. Часть 6. Некоторые реализации Garbage Collector.

– Serial GC
Это последовательная сборка молодого и старого поколения в области памяти Java.

– Parallel GC
Работает также как и Serial GC, но с использованием многопоточности.

– CMS GC (Concurrent Mark–and–Sweep)
Для сборки мусора задействуются несколько потоков, и происходит это через такой же алгоритм, как в Parallel GC.
Использовался до Java 8 и G1.

– G1 GC
Был задуман как замена CMS и разрабатывался для многопоточных приложений, которые характеризуются крупным размером кучи (более 4 ГБ).

– Epsilon
Был выпущен как часть JDK 1. Не реализует никакого реального механизма восстановления памяти. Как только доступная куча исчерпана, JVM завершает работу.

– Shenandoah
Выпущен как часть JDK 12. Ключевое преимущество перед G1 в том, что G1 может эвакуировать области кучи только тогда, когда приложение приостановлено, а Shenandoah перемещает объекты одновременно с приложением.

– ZGC
Выпущен как часть JDK 11 и улучшен в JDK 12. Предназначен для приложений, требующих низкой задержки (паузы в менее чем 10 мс) или задействующих очень большую кучу (несколько терабайт).

👩‍💻 Наш практический курс Java–разработчика

✅ JavaStart. Подписаться