Ответ Питера верен в том смысле, что -Xms
выделяется при запуске, и он вырастет до -Xmx
(максимальный размер кучи), но это немного вводит в заблуждение, как он сформулировал свой ответ. ( Извините, Питер, я знаю, вы знаете, что это холодно ).
Настройка мс == мх эффективно отключает это поведение. Хотя раньше это было хорошей идеей в старых JVM , это уже не так. Увеличение и уменьшение кучи позволяет JVM адаптироваться к увеличению нагрузки на память, но при этом сокращает время паузы за счет уменьшения кучи при уменьшении нагрузки на память. Иногда такое поведение не дает ожидаемых преимуществ с точки зрения производительности, и в этих случаях лучше установить mx == ms .
OOME генерируется, когда куча превышает 98%
времени, потраченного на сбор, и коллекции не могут восстановить более 2%
этого. Если вы не достигли максимального размера кучи, JVM просто вырастет так, что вы выйдете за эти границы. Вы не можете иметь OutOfMemoryError
при запуске, если ваша куча не достигает максимального размера кучи и не отвечает другим условиям, которые определяют OutOfMemoryError
.
За комментарии, которые пришли с тех пор, как я написал. Я не знаю, что показывает запись в блоге JMonitor , но это от сборщика PSYoung
.
size_t desired_size = MAX2(MIN2(eden_plus_survivors, gen_size_limit()),
min_gen_size());
Я мог бы больше копаться, но готов поспорить, что найду код, который служит той же цели в реализациях ParNew
и PSOldGen
и CMS Tenured
. На самом деле маловероятно, что CMS сможет вернуть память, если не было Concurrent Mode Failure
. В случае CMF
будет работать последовательный сборщик, который должен включать сжатие, после которого вершина кучи, скорее всего, будет чистой и, следовательно, может быть освобождена.