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

Конструктор в Java. Часть 2.

Зачем нужны конструкторы?

1) Инициализация объектов.
Конструкторы позволяют установить начальные значения полей объекта при его создании.

2) Предоставление гибкости.
Конструкторы могут принимать параметры, что делает возможным создание объектов с различными характеристиками.

3) Выполнение дополнительных действий.
В конструкторе можно реализовать дополнительные логику, которая будет выполнена при создании объекта.

Типы конструкторов:

1) По умолчанию (default).
Если вы не создаете явно конструктор, компилятор Java добавит конструктор по умолчанию без параметров (на Картинке).

2) С параметрами.
Принимает параметры для инициализации объекта.

Важный момент:

Если вы явно определяете хотя бы один конструктор в классе, компилятор больше не добавит конструктор по умолчанию!

Подытожим:

Конструкторы - это ключевой элемент создания объектов в Java. Они обеспечивают начальную настройку объектов, делая ваш код более структурированным и управляемым.

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

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

Вакансия для Go разработчиков 😁👍

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

Garbage Collector в Java. Часть 1.

Перейдем с вами к большой теме под названием Garbage Collector.

Поиском и освобождением ненужных участков в памяти в JVM занимается специальный процесс, который называется Garbage Collector или коротко GC. У Garbage Collector всего две задачи – это обнаружение и очистка мусора.

Мусор – это структура данных (объект) в памяти не достижимый из программного кода.

Как работает Garbage Collector:

1) Маркировка (Marking).
GC определяет, какие объекты доступны для использования, и маркирует их.

2) Определение объектов для удаления.
GC определяет объекты, которые не помечены как доступные для использования (мусор).

3) Освобождение памяти.
GC освобождает память, занятую удаленными объектами, делая ее доступной для новых объектов.

В следующих постах разберем различные реализации Garbage Collector и подходы для поиска мусора.

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

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

Garbage Collector в Java. Часть 2.

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

По спецификации нет никаких правил для реализации GC, кроме соблюдения корректности – это значит, что нельзя собирать объекты, которые в будущем в приложении будут использоваться.

Мы уже много раз замечаем слово "ненужные" объекты. Но как определить, что объект не нужен, что объект не используется и это мусор?

Существует несколько подходов для поиска мусора:

– Reference counting
– Tracing (GC Root)

Поговорим об этих подходах далее.

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

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

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

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. Подписаться