2011-12-15 2 views
0

Предположим, у меня есть приложение, которое имеет утечку памяти. В какой-то момент GC будет очень стараться очистить память и замедлит мое приложение. Я знаю, что если вы установите этот параметр для JVM -XX: -UseGCOverheadLimit он выбросит OutOfMemoryException:Как предотвратить сборщик мусора, чтобы замедлить мою заявку

, если более 98% от общего времени тратится в процессе сборки мусора и менее 2% от кучи восстанавливается.

Однако это как-то не очень хорошо для меня. Потому что мое приложение будет очень медленным даже до того, как эти числа попадут. GC поглотит процессор в течение некоторого времени до того, как OutOfMemoryException будет выбрано. Моя цель - как-то распознать очень рано, если будет наиболее похоже проблема, а затем выбросить OutOfMemoryexception. После этого у меня есть какая-то стратегия восстановления.

Теперь я нашел эти два дополнительных параметра GCTimeLimit и GCHeapFreeLimit. С ними можно настроить две котируемые константы (98% и 2%).

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

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

+9

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

+3

Не кажется ли более разумным исправить утечку памяти? Это похоже на капельницу под утечкой памяти. – corsiKa

+0

Какой JVM? Какая версия? Параметры/методы настройки GC являются собственностью каждой реализации JVM. –

ответ

0

Боковой шаг кучи JVM и используйте что-то вроде Terra Cotta's Big Memory, которое использует управление прямой памятью, чтобы расти вне досягаемости сборщика мусора.

0

Если вы используете Sun/Oracle JVM, то страница this кажется довольно полным GC-tuning primer.

+0

Два ответа? Почему бы просто не отредактировать первый? – mre

+1

@ Крыс Потому что это два очень разных ответа, которые предоставляют несколько вариантов решения проблемы. –

1

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

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

+0

Я подумал о аналогичном решении.Но проблема в том, что действительно сложно сказать, является ли поведение просто тяжелой ситуацией или утечкой памяти. Это не проблема, если приложению требуется много памяти, если она снова освобождается. Проблема возникает, если из каждой коллекции что-то осталось. – kukudas

+0

Из-за звука этого сборщика мусора выбивается из-за того, что не хватает неперечисленных объектов для выпуска. Если это происходит после запуска некоторое время, а не в ответ на определенный набор условий, который является довольно классическим симптомом утечки памяти в Java. Вы должны проверить свою кучу - http://stackoverflow.com/questions/145922/how-can-i-see-what-is-in-my-heap-in-java – patros

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