Сборка "мусора" Java

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

Действительно ли он может обрабатывать все неиспользуемые объекты

Нет, может ' т. Однако он может собирать все объекты, которые больше нельзя использовать , и делает это очень хорошо. Разница небольшая, см. Ниже.

Объяснение

Например, у вас есть следующий код:

class A {
    public static Date d = new Date(); // d will never be collected
}

И скажем вы знаете, что через определенное время к d больше не будет доступа. Однако в системе времени выполнения этой информации нет, и d будет оставаться в живых неопределенно долго, тогда как в C ++ вы можете явно удалить его.

Вместо этого сборщик мусора собирает все объекты , которые больше не доступны .Например:

void f() {
    Date d = new Date();
    System.out.println(d.toString());
} // d is no longer accessible at this point

Сборщик мусора обнаруживает, что объект, на который ссылается d , не будет когда-либо снова доступен, поскольку d является его единственной ссылкой и выходит за рамки в конце метода. Сбор недоступных объектов - это недооценка вопроса «какие объекты можно собирать», но это безопасно, поскольку гарантирует, что ни один живой объект никогда не будет собран.

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

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

Я не могу сказать за C, но в C++ мы на самом деле очень редко используем полноценный сборщик мусора, потому что у программистов C++ есть такие методы, как RAII и интеллектуальные указатели подсчета ссылок, которые помогают упростить управление памятью.

Для .NET посмотрите Garbage Collector Basics and Performance Hints Там вы также найдете несколько советов по производительности.

Для Java посмотрите Теория и практика Java: Сборка мусора и производительность. Там вы также найдете некоторые подсказки и "анти-подсказки", т.е. способы ухудшить работу GC.

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

Использование языка, который требует, чтобы вы сами выделяли, освобождали и перераспределяли пространство (например, C), может быть очень сложным, поскольку вам нужно полностью контролировать выделение пространства для любого объекта, который вам нужен, и удаление любого объекта, с которым вы закончили, не забывая о ненужных объектах, которые сидят где-то рядом и используют пространство. Как бы сложно это ни было, это имеет преимущество в производительности.

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