Запускается ли сборка мусора в Java для предотвращения перестановки памяти?

Question

В качестве примера скажем, что я установил максимальную кучу JVM на 4 ГБ. Тем не менее, как только мое приложение достигает около 3 ГБ, ОС начинает переставлять часть памяти на диск. На данный момент уже несколько объектов находятся вне области видимости, и вместо того, чтобы запрашивать больше памяти, JVM может сначала собрать мусор старыми объектами. С точки зрения производительности было бы лучше запустить сборщик мусора, чем выполнять обмен памяти. Умна ли сборка мусора в JVM в подобных ситуациях или совершенно не знает об этом? Можем ли мы как-то настроить JVM для решения этой ситуации?

Я знаю, что есть шанс, что сборка мусора запустится до того, как мы достигнем 3 ГБ, и поэтому нам на самом деле не нужно менять память, но это не отвечает на мой вопрос.

EDIT: предположим, что на моей машине больше 4 ГБ памяти, но иногда есть другие приложения, которые занимают часть этой памяти, оставляя мне менее 4 ГБ. Я бы предпочел не уменьшать максимальный размер кучи, учитывая, что в большинстве случаев у меня будет 4 ГБ, но мне было интересно, будет ли GC достаточно умным в других ситуациях.

Answer 1

JVM, к счастью, не знает о нижележащем управлении памятью ОС.Я помню, как недавно посещал сессию JavaOne, посвященную оптимизации GC, и оратор подчеркнул, что вы всегда должны обеспечивать наличие достаточного объема свободной памяти (ОЗУ, а не подкачки) для запуска JVM, чтобы избежать подкачки любой ценой, поэтому никогдавыделите больше памяти для JVM, чем то, что у вас есть в данный момент в вашей системе.Более того, из-за того, как работают некоторые алгоритмы сбора GC, это может привести к огромным потерям производительности, если блоки собираемой ими памяти выгружаются.

Поэтому никогда не отдавайте JVM больше памяти, чем физически доступно в вашей системе, или если вы ожидаете, что потребление памяти со временем возрастет из-за некоторых внешних процессов, выделите пространство кучи, которое гарантирует, что оно никогда не будетбыть подкачаннымИ если вы не можете удовлетворить эти условия, тогда вам нужно больше оперативной памяти:)

Обновление: немного поискал в SO, и я нашел this .Здесь kdgregory утверждает, что подкачка не должна быть проблемой из-за того, как работает GC, но он рассматривает подкачку из-за нормальных условий, то есть памяти не трогают какое-то время, а это не ваш случай, потому что у вас закончитсяпамять, и вы обязательно начнете пейджинг.Кроме того, в случае, если вы используете какой-то вкус Linux, проверьте ответ Джона Ферминеллы и его замечательное сообщение в блоге , объясняющее, как понять и настроить своп в Linux.

Answer 2

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

На самом деле не думаю, что даже в C есть простой способ проверить, не поменялся ли процесс (возможно, если есть, добавьте комментарий).

Answer 3

[...] структура памяти областей данных времени выполнения, используемый алгоритм сбора мусора и любая внутренняя оптимизация инструкций виртуальной машины Java (например, перевод их в машинный код) оставляются на усмотрение исполнителя ^{(спецификация виртуальной машины Java, глава 3)}

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

Технически это будет, по крайней мере, проблемой. Потому что мы не хотели бы запускать gc на том факте, что некоторые страницы были перенесены в виртуальную память, но мы хотели бы запустить gc, когда управление памятью собирается поменять jvm страниц виртуальная память. И я сомневаюсь, что такая информация / уведомление доступно в компьютерной системе.

«ОС на JVM: эй, лучше очистить сейчас, прежде чем я переставлю часть вашей кучи в виртуальную память» - «JVM на ОС: ОК, пожалуйста, не меняйте местами, начинайте чистить сейчас, говорите когда закончите "- 1457ms позже -" JVM to OS: спасибо за ваше терпение, вычистил как можно больше, вы можете продолжить замену сейчас )