Использование размера кучи Java

Question

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

Я запускаю свою программу с параметром -Xmx4m.Действительно ли нужно более 4 мегабайт, чтобы быть в развернутом состоянии?

Еще один вопрос: если я запускаю java visualVM, я вижу диаграмму использования моей программы с острыми краями, в то время как другие программы, использующие javaВМ (такие как netbeans) имеют больше прямолинейных диаграмм.Почему использование кучи моей программы так нестабильно, даже если она ничего не делает (только ждет, пока пользователь нажмет кнопку)?

Answer 1

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

-XX: + HeapDumpOnOutOfMemoryError

Типичное «маленькое» настольное Java-приложение в 2011 году будет работать с ~ 64-128 МБ. Если у вас нет действительно насущных потребностей, я бы начал с того, что оставил для него значение по умолчанию (то есть без настроек).

Если вы пытаетесь сделать что-то другое (например, запустить это на устройстве Android), вам нужно очень хорошо освоиться с профилированием (и вам, вероятно, следует опубликовать этот тег).

Имейте в виду, что ваш кэш 100 записей (~ 12 байт) может (вероятно) удвоиться, если вы храните символьные данные (Java использует UCS-16 для внутреннего использования).

RE: «нестабильность», JVM будет обрабатывать использование памяти для вас и будет выполнять сборку мусора в соответствии с любыми выбранными им алгоритмами (они сильно изменились за эти годы). Графики могут быть просто артефактом инструмента и периода выборки. На производительность в настольном приложении влияет огромное количество факторов .

В качестве примера, у нас когда-то была огромная утечка памяти, которая обнаруживалась только в одном автоматизированном тесте, но никогда не обнаруживалась при обычном использовании в реальном мире. Оказалось, что тест оставил курсор мыши над подсказкой, в которой было имя открытого файла, который в свою очередь содержал набор ссылок на весь (огромный) проект. Покачивая мышь, несколько пикселей избавились от всплывающей подсказки, что означало, что все ссылки очистились, и сборщик мусора вытащил мусор.

Мораль этой истории? Вам нужно захватить точный дамп кучи во время нехватки памяти и внимательно просмотреть его.

Answer 2

Вам может потребоваться более 4 МБ для графического интерфейса пользователя с расширенным экраном, если вы используете двойной буфер.Это создаст несколько изображений пользовательского интерфейса.Это делает это, чтобы быстро показать их на экране.Обычно это делается, если у вас много памяти.

Распределение памяти Sawtooth происходит из-за того, что что-то делается, а затем собирается мусор.Это может быть операция перекраски или другой таймер.Есть ли в вашем коде таймер, чтобы проверить, какой процесс или значение изменяется.Или вы добавили код для перерисовки объекта или другого процесса?

Answer 3

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

Это также зависит от того, сколько объектов создается и уничтожается вашим кодом, и от базового Swing (япри условии, что компоненты используют компоненты для рисования элементов, и как эти элементы создаются и уничтожаются каждый раз, когда компоненты перерисовываются.Посмотрите на код CellRenderer, и он покажет вам, почему объекты часто создаются и уничтожаются, и почему сборщик мусора делает такую ​​замечательную работу.

Попробуйте поиграть с настройкой Xmx и посмотрите, как диаграммы сглаживаются.Я ожидаю, что Xmx64m или Xmx128m подойдут (хотя объем данных, поступающих из вашей базы данных, очевидно, будет важным фактором.

Answer 4

Я думаю, что 4 МБ слишком мало для всего, кроме тривиальной программы - например, многим библиотекам GUI (включая Swing) потребуется выделить временное рабочее пространство для графики, которая сама по себе может превысить эту сумму.

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

• Xmx (максимальный размер кучи), как правило, должен быть довольно большим, например, 256 МБ
• Xms (начальный размер кучи) может быть намного меньше, 4 МБ должно работать - хотя помните, что еслиприложению нужно больше, чем это, временное снижение производительности при изменении его размера