Какая польза от методов сбора мусора в Java?

Question

System.gc () или Runtime.gc (), если вы звоните, нет гарантии, что будет сборка мусора.Это до JVM, чтобы выполнить GC.Тогда какой смысл в таких методах?

Answer 1

Вы правы, gc() звонки не должны предоставляться в первую очередь, когда нет варианта использования.Я могу вспомнить хотя бы один положительный и два отрицательных момента использования явных вызовов GC: * ​​1002 *

1. Если вы создаете приложение, в котором у вас мало контроля над параметрами JVM и вы хотите достичь какого-то Боганастройка уровня из кода, вы можете использовать явный вызов.Но будьте уверены, что это не волшебный вызов для выполнения GC в сценариях, где вы неожиданно ожидаете низкой нагрузки в течение нескольких минут.Вам может потребоваться приложить немало усилий для достижения этой цели, например, оценить скорость отклика GC, объем собираемой памяти и т. Д.

2. System.gc() или Runtime.getRuntime().gc() могут служитьнапоминание или предложение, но это полностью прерогатива JVM - делать это или нет.Напротив, он может вообще ничего не делать, увидев такой запрос.Ссылка: Oracle Java

3. Сказав это, этого обычно избегают, потому что GC - это то, что можно контролировать и обрабатывать с помощью внешних параметров JVM, а не из самого кода.Например: -XX: -DisableExplicitGC

Answer 2

Javadoc для System.gc() и Runtime.gc() указывает на тот факт, что можно настроить JVM для игнорирования вызовов этих методов;например, с использованием опции -XX:+DisableExplicitGC JVM.

Однако они не настроены таким образом по умолчанию (по крайней мере, в текущих версиях Oracle и OpenJDK Java).Таким образом, вызовы будут делать что-то по умолчанию.

Сказав это, в большинстве случаев плохая идея вызывать сборщик мусора напрямую.В тех немногих случаях, когда это оправдано, в основном рассматриваются следующие вопросы:

• , если вы пытаетесь исследовать или тестировать поведение кода, чувствительного к ГХ;например, финализаторы

• , если вы пытаетесь избежать паузы ГХ в неудобной точке, запустив ГХ в точке, где пользователь не заметит.

---

Я не понимаю, что плохого в предоставлении гарантированного GC, когда я запрашиваю System.gc()?

Когда вы можете вызывать сборщик мусора черезgc() вызов, обычно делает полную коллекцию.Это дорого, особенно если объем данных без мусора велик ¹ .К сожалению, многие программисты на Java этого не понимают.Итак, (насколько я понимаю) основная причина, по которой опция JVM игнорирует явные вызовы gc(), состоит в том, чтобы смягчить потенциально катастрофическое влияние на производительность программистов , злоупотребляющих методом.

Если вы do , чтобы ваши System.gc() вызовы вызывали GC, лучший совет - не включайте -XX:+DisableExplicitGC в параметры JVM.

Прочтите руководство Oracle.для команды java для получения дополнительной информации.

^{1 - Большая часть времени выполнения сборки мусора заключается в отслеживании и копировании графа объектов, которые все еще доступны.Если вы скажете сборщику запустить его до того, как он понадобится, вы снизите его эффективность.Напротив, сама JVM знает, когда куча заполнена или достаточно близка, чтобы гарантировать сбор.Действительно, он может оптимизироваться для двух разных требований;максимизация пропускной способности или минимизация времени паузы ГХ.}

Answer 3

По сути, вы правы, говоря, что нет гарантии, что jvm действительно запустит gc сразу после вашего System.gc() вызова.Однако gc может принять к сведению ваше желание сделать коллекцию сейчас и запустить ее.

Это зависит от jvm, но, насколько я знаю, точка доступа jvm фактически запускает gc после System.gc() или Runtime.gc() припо крайней мере, в большинстве случаев.

Так что я бы сказал, что отсутствие хотя бы одного способа предложить vm запустить gc было бы ошибкой.Могут быть разные реализации vm, и что если есть vm, который хочет предоставить возможность вызова gc с гарантией того, что он действительно будет работать после такого вызова, он не нарушит спецификацию и может быть полезен в некоторых случаях, и какЯ уже упоминал, что hotspot vm скорее всего не будет игнорировать этот вызов.

Answer 4

Эти методы предоставляются, если кто-то хочет завладеть сборщиком мусора (который был действителен для старых JVM), но всегда целесообразно оставлять часть мусора в JVM, особенно в современных реализациях JVM предусмотрены высоко оптимизированные сборщики мусора.Наша работа стала проще благодаря современным реализациям JVM, поэтому мы должны сосредоточиться только на Java-коде.

Answer 5

Из Java 7 документов

public static void gc ()

Запускает сборщик мусора.

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

Вызов System.gc () фактически эквивалентен вызову:

Runtime.getRuntime (). Gc ()

Итак, по сути, это предложение для эвристики GC, что сейчас самое время освободить немного памяти.Например, скажем, вы пишете игру, в которой частота кадров ограничена до 60 кадров в секунду.Каждый кадр имеет бюджет 16,6 (повторяя, конечно;)) миллисекунды.Скажем, ваш кадр занимает всего 5 мс для запуска.Обычно вы ожидаете оставшееся время с Thread.sleep.Однако вместо этого вы могли бы сначала позвонить System.gc(), чтобы сказать ВМ: «Эй, у меня есть дополнительное время - не стесняйтесь убирать, пока я жду».Конечно, у вас нет никаких гарантий, что сборка мусора займет меньше, чем оставшиеся 11,6 мс!Но если все сделано осторожно, это может помочь использованию вашей памяти и предотвратить сбор мусора в неподходящее время.Аналогичные принципы применимы к другим типам приложений - в основном, если вы знаете, что ваше приложение будет иметь некоторое время простоя, вы можете сообщить об этом виртуальной машине с помощью System.gc() и, надеюсь, помешать GC вместо этого принять решение о выполнении в середине чего-то важного.