Затраты Java GC: имеет ли значение, если у вас есть 10 МБ или 10 ГБ * ссылочных * объектов?

Question

ГХ должен проверить и выяснить, какие объекты можно собрать.Мой вопрос заключается в том, может ли слишком большое количество объектов для проверки привести к накладным расходам GC, или GC достаточно умен, чтобы избежать необходимости перебирать все объекты, чтобы выяснить, на какой из них больше нет ссылок?

Answer 1

Да, для имеет значение , сколько у вас объектов. Что касается размера этих объектов, это тоже может иметь значение: у компактного сборщика будет больше работы, если ему нужно будет сжать 10 ГБ, а не 10 МБ.

Сказав это, современные сборщики мусора чрезвычайно сложны (они работают с несколькими кучами, работают в фоновом режиме, могут использовать несколько ядер и т. Д.). Они также легко настраиваются. Кроме того, типичная JVM оснащена несколькими сборщиками мусора.

Поэтому трудно дать значимые, точные ответы на общие вопросы, подобные этому.

Answer 2

Одним из способов оптимизации такого рода вещей является концепция Generations Garbage Collection . (Смотрите в Разделе 4). Судя по всему, у Java начиная с 1.2 была коллекция поколений.

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

Это позволяет вам не смотреть на все активные объекты для каждой развертки.

Answer 3

Это зависит от того, какой алгоритм GC используется, в случае развертки маркера это имеет значение, потому что анализ развертки должен идентифицировать корни для GC, используя перечисление. Вот ссылка на то, как работает mark-sweep

Answer 4

Он должен перебирать все активные объекты, чтобы определить, используется ли объект до сих пор. Коллектор G1 имеет 1 МБ мегаобъекта (который знает все ссылки в пределах 1 МБ), но производительность практически одинакова.

Когда вы получаете решения с несколькими ГБ, одним из вариантов является использование кучи памяти, которой вы управляете сами. Или вы можете использовать решение типа Zing , которое может обрабатывать десятки ГБ кучи без значительных пауз.