Являются ли соотношения между пробелами / поколениями в куче Java постоянными?
Я прочитал эту статью о настройке сборки мусора виртуальной машины, чтобы лучше понять сборщик мусора Java. Каждое пространство имеет область виртуального пространства кучи, в которую оно может расти, когда необходимое пространство кучи приближается к максимальному размеру кучи. Это можно увидеть на этом рисунке: http://www.oracle.com/ocom/groups/public/@otn/documents/digitalasset/190244.gif
Вы можете установить соотношение между Young Generation и Old (Tenured) Generation с помощью параметра NewRatio, а соотношение между Eden Space и Survivor Space - с помощью параметраSurvivorRatio.
Недавно был задан вопрос о том, как узнать коэффициенты по умолчанию для кучи. В нем говорится, что вы должны использовать параметр PrintGCDetails и рассчитать коэффициенты вручную.
У меня такой вопрос: увеличивается ли размер разных пространств кучи на одно и то же соотношение, сохраняя, таким образом, соотношение, установленное между ними, при постоянном запуске в течение всего времени выполнения приложения? Например, если для Young Generation и Old/Tenured Generation значение NewRatio по умолчанию равно 3, а начальное зарезервированное пространство кучи составляет 100 МБ для Young, и 300 МБ для Old. Если для старого пространства необходимо зарезервировать больше памяти, скажем, 300 МБ, то есть 600 МБ. Память, зарезервированная для Young Space, также удваивается до 200 МБ, сохраняя соотношение в целости?
3 ответа
Я думаю, что вы имеете в виду эргономику GC и политику адаптивного размера
- особенность Hotspost GC, которая автоматически адаптирует размеры поколений во время выполнения на основе текущего поведения выделения запущенного приложения.
- Эта функция включена по умолчанию и контролирует / адаптирует размер поколений во время выполнения.
- на самом деле, некоторые параметры GC будут игнорироваться, если вы не отключите политику адаптивного размера, например.
-XX:SurvivorRatio=,
Вы можете отключить Адаптивную Политику Размера, используя -XX:-UseAdaptiveSizePolicy, После того, как вы отключили AdaptiveSizePolicy, GC будет учитывать начальный размер поколений, указанный в параметрах запуска (например, -Xms, -Xmx, -XX:MaxNewSize=,-XX:NewSize=, -XX:SurvivorRatio=) и они останутся постоянными.
Вы можете найти больше информации о политике адаптивного размера в UseAdaptiveSizePolicy и других опциях jvm.
Соотношение PermGen vs Young частично поддерживается JVM, но если сказать, что соотношение поддерживается, ответ - нет.
JVM7 стала достаточно продвинутой и сложной, где мы не должны предсказывать распределение поколений внутри кучи.
В каждом цикле GC, который запускает JVM, он также выполняет метрический анализ, чтобы узнать о текущем поведении приложений в памяти. - Если в нескольких циклах GC выживает больше объектов, то PermGen уменьшается и часть пространства выделяется для YoungGeneration. В принципе No. of objects Икс number of GC cycles they skip играет критерий в динамической настройке коэффициента генерации.
Надеюсь, это поможет, спасибо.
Редактировать: Я думаю, что у меня может быть что-то не так. Разместите эту заметку здесь, пока я расследую, чтобы не отправлять людей по неверному пути!
Ответ Ales0x хорош, если вы используете Parallel Scavenge GC (-XX:+UseParallelGC), но одновременный Mark-Sweep GC (-XX:+UseConcMarkSweepGC) не поддерживает адаптивную калибровку.
С Concurrent Mark-Sweep размер нового / молодого поколения устанавливается на основе начального размера кучи (если вы не укажете -XX:NewSize=). Размер нового поколения не изменится с ростом кучи.