Какой размер кучи вы предпочитаете?

Обычно я стараюсь не использовать кучи размером более 1 ГБ. Это будет стоить вам больших сборов мусора.

Иногда лучше разделить ваше приложение на несколько JVM на одном компьютере, а не на кучу большого размера.

Основная коллекция с большим размером кучи может занять> 10 минут (в неоптимизированных приложениях GC).

На самом деле я всегда считал очень странным, что Java ограничивает размер кучи. Собственное приложение обычно может использовать столько кучи, сколько ему нужно, пока не исчерпается виртуальное адресное пространство. Единственная причина ограничить кучу в Java - это сборщик мусора, который имеет определенную «лень» и не может собирать мусор для объектов, если в этом нет необходимости. Это означает, что если вы выберете слишком большую кучу, ваше приложение будет постоянно использовать больше памяти, чем действительно необходимо.

Тем не менее, Sun за эти годы значительно улучшила сборщик мусора, и для имитации поведения собственного приложения на C я бы установил начальный размер кучи 32 МБ (для небольших программ) или 64 МБ (для более крупных), а максимальный - равным что-то между 1-2 ГБ. Если вашему приложению действительно требуется более 1 ГБ памяти, оно, скорее всего, сломано (если вы не имеете дело с такими большими объектами данных), но я не вижу причин, по которым ваше приложение должно быть уничтожено только потому, что оно превышает определенный размер кучи.

Конечно, это относится к обычным ПК. Если вы создаете код Java для мобильных телефонов или других ограниченных устройств, вам, вероятно, следует адаптировать начальный и максимальный размер кучи в соответствии с ограничениями этого устройства.

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

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

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

первое что сделал - нарастил кучу до 1 гига. это избавило от проблем с нехваткой памяти, но все равно было медленным. Я также заметил, что IDEA регулярно зависала на 10 секунд или около того, после чего использованная память была сокращена вдвое только для того, чтобы снова нарастить, и это вызвало идею сборки мусора. Теперь я использую его с -Xms512m, -Xmx768m, но я также добавил -Xincgc, чтобы активировать добавочную сборку мусора.

В результате мне вернули старую IDEA: она работает плавно, больше не зависает и никогда не использует более 600 м кучи.

Для вашего приложения вы должны использовать аналогичный подход. попробуйте определить типичное использование памяти и настроить кучу, чтобы приложение хорошо работало в этих условиях. Но также позвольте опытным пользователям настроить этот параметр, чтобы справиться с нестандартной загрузкой данных.

Это зависит от типа приложения. Настольное приложение сильно отличается от веб-приложения. Сервер приложений сильно отличается от отдельного приложения.

Это также зависит от используемой JVM. JDK5 и более поздние версии 6 включают улучшения, которые помогают понять, как настроить ваше приложение.

Размер кучи важен, но также важно знать, как он работает со сборщиком мусора.

JDK1.4 Настройка сборщика мусора

Настройка сборщика мусора JDK5

Настройка сборщика мусора JDK6

Вам нужно потратить некоторое время на JConsole или visualvm, чтобы получить четкое представление о том, каково плато использования памяти. Подождите, пока все стабилизируется и вы увидите характерную пилообразную кривую использования памяти кучи. Пики должны составлять 70-80% кучи, в зависимости от того, какой сборщик мусора вы используете.

Большинство сборщиков мусора запускают полные сборщики мусора, когда использование кучи достигает определенного процента. Этот процент составляет от 60% до 80% от максимальной кучи, в зависимости от того, какая стратегия задействована.

1,3 ГБ для тяжелого приложения с графическим интерфейсом.

К сожалению, в Linux JVM, похоже, предварительно запрашивает 1,3 Гб виртуальной памяти в этой ситуации, что выглядит плохо, даже если она не нужна (и вызывает много недоуменного ворчания со стороны пользователей).

В моем приложении с наиболее интенсивным использованием памяти:

-Xms250M -Xmx1500M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC