Может JVM макс. размер "кучи" быть динамичной?
JVM-Xmx аргумент позволяет тому установить макс. размер "кучи" для JVM к некоторому значению. Но, есть ли способ сделать то значение динамичным? Другими словами, я хочу сказать, что JVM "смотрит при необходимости в ней просто продолжайте брать RAM от системы, пока система не отсутствует".
Причина с двумя частями выяснения: Во-первых, рассматриваемое приложение может использовать действительно широкий спектр поршня в зависимости от того, что делает пользователь, таким образом, концептуальная минута и макс. значения довольно далеко друг от друга. Во-вторых, казалось бы, что JVM резервирует макс. пространство "кучи" от виртуальной памяти во время начальной загрузки. Это конкретное приложение запущено на довольно большом разнообразии аппаратных средств, так выбор "единого" макс. пространства "кучи" труден, так как это должно быть достаточно низко для работы низкопроизводительных аппаратных средств, но мы действительно хотели бы смочь использовать в своих интересах действительно раскормленные машины, если они доступны.
3 ответа
Но есть ли способ сделать это значение динамичным?
Буквально нет. Максимальный размер кучи устанавливается во время запуска JVM и не может быть увеличен.
На практике вы можете просто установить максимальный размер кучи настолько большим, насколько позволяет ваша платформа, и позволить JVM увеличивать кучу по мере необходимости. В этом есть очевидный риск; то есть ваше приложение будет использовать всю память и заставит машину пользователя останавливаться. Но этот риск подразумевается в вашем вопросе.
РЕДАКТИРОВАТЬ
Стоит отметить, что существуют различные параметры настройки -XX ... GC, которые позволяют настраивать способ расширения кучи JVM (до максимального значения).
Другая возможность - разделить ваше приложение на 2 части. Первая часть приложения выполняет всю подготовку, необходимую для определения «размера» проблемы. Затем он определяет соответствующий максимальный размер кучи и запускает вторую часть приложения, требующую много памяти, в новой JVM.
Это работает, только если приложение можно разумно разделить, как указано выше.
Это работает, только если возможно вычислить размер проблемы. В некоторых случаях вычисление размера проблемы равносильно вычислению результата.
Непонятно, повысится ли общая производительность, если вы просто позволите куче вырасти до максимального размера.
Нет. Это могло бы и, вероятно, должно:
-Xmx90% // 90% of physical memory
Однако неявное значение по умолчанию, 100%, вероятно, не является хорошей идеей.
Программа, написанная на языке, отличном от GC, очень старательно управляет своей памятью, она удалит весь мусор при первой возможности. Имеет смысл разрешить ему получать любую запрашиваемую память, предполагая, что он отвечает за быстрое удаление мусора.
У GC другой язык. Собирает мусор только при необходимости. Пока есть место, он не заботится о том, чтобы мусор оставался поблизости. Если бы он мог получить всю необходимую память, он бы получил всю память компьютера.
Таким образом, программисту сборщика мусора больше не нужно беспокоиться об удалении каждого куска мусора, но он все равно должен иметь общее представление о допустимом соотношении «мусор / живые объекты» и указывать сборщик мусора с помощью -Xmx.
По сути, вы не можете адаптироваться к оборудованию различных пользователей, используя чистую Java: тогда может пригодиться небольшая часть сценариев оболочки / пакетной обработки.
Я так и делаю в OS X и Linux: у меня есть небольшой сценарий оболочки bash , который заботится о поиске правильных параметров JVM в зависимости от оборудования, на котором запущено приложение, а затем вызывает JVM.
Обратите внимание, что если вы предоставляете настольное приложение Java, вы можете использовать что-то вроде izpack, чтобы предоставить своим пользователям установщик:
Я не знаю на все, если Java Web Start может быть использован для предоставления различных параметров JVM в зависимости от конфигурации пользователя (вероятно, нет, и JWS действительно работает в любом случае, если вы планируете предоставить профессионально выглядящее настольное приложение).