2015-07-17 2 views
0

Я контролирую приложение Java, работающее на Jvm 6. Здесь скриншот панели jvisualVM 1.Как Jvm6 уменьшает размер кучи, когда это не необходимо

Я заметил, что когда размер кучи мал (до 12:39 на картинке), сборщик мусора работает часто. Затем я запускаю дорогостоящую задачу памяти пару раз (с 12:39 до 12:41), и пространство кучи растет. Почему с этого момента сборщик мусора работает реже?

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

Есть ли что-то, что я могу сделать, чтобы избежать такого поведения? Имеет ли новое Java8 VM другое поведение?

ответ

1

Поведение выглядит нормальным.

До 12:39 на снимке прикрепленного профиля не так много GC.

Затем вы запускаете свои задачи и, поскольку объекты, которые больше недоступны, становятся доступными для GC, sweep отмечает их, и они удаляются.

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

Каждый основной выпуск платформы включает некоторые изменения и улучшения JVM и GC, но поведение приложения будет очень похоже на Hotspot 7/8. Попробуй.


Современные JVMs высоко оптимизированные сборщики мусора и вам не нужно беспокоиться о том, как/когда она высвобождает память, но больше о том, что вы отпустите объекты, чтобы они получают право на инкассо. Как часто после запуска вы испытываете проблемы с памятью?

Если вы получаете сбои из-за недостатка памяти настройки виртуальной машины Java, чтобы сделать дамп кучи на выходе: -XX: + HeapDumpOnOutOfMemoryError -XX: HeapDumpPath = date.hprof

+0

Я начал этот анализ после нескольких необычных сбоев. Я думаю, что моя проблема в основном - «дорогостоящая задача памяти». Но я блуждал, почему размер кучи занял столько времени, чтобы ослабить и как предотвратить это поведение. – Panciz

2

ли есть ли что-то, что я могу сделать, чтобы избежать такого поведения?

Комплект -XX:MaxHeapFreeRatio=30 -XX:MinHeapFreeRatio=15, который более агрессивно уменьшит размер кучи. Обратите внимание, что не все реализации GC дают память, которую они не используют обратно в ОС. По крайней мере, G1 делает, но это недоступно на java 6.

Смежные вопросы