Предположим, у меня есть приложение, которое имеет утечку памяти. В какой-то момент GC будет очень стараться очистить память и замедлит мое приложение. Я знаю, что если вы установите этот параметр для JVM -XX: -UseGCOverheadLimit он выбросит OutOfMemoryException:Как предотвратить сборщик мусора, чтобы замедлить мою заявку
, если более 98% от общего времени тратится в процессе сборки мусора и менее 2% от кучи восстанавливается.
Однако это как-то не очень хорошо для меня. Потому что мое приложение будет очень медленным даже до того, как эти числа попадут. GC поглотит процессор в течение некоторого времени до того, как OutOfMemoryException будет выбрано. Моя цель - как-то распознать очень рано, если будет наиболее похоже проблема, а затем выбросить OutOfMemoryexception. После этого у меня есть какая-то стратегия восстановления.
Теперь я нашел эти два дополнительных параметра GCTimeLimit и GCHeapFreeLimit. С ними можно настроить две котируемые константы (98% и 2%).
Я сделал некоторые тесты самостоятельно, как небольшой фрагмент кода, который вызывает утечку памяти и воспроизводит эти настройки. Но я не уверен, как найти правильный компромисс. Я надеюсь, что кто-то другой столкнулся с такой же проблемой и придумал разумное решение, или, может быть, есть некоторые другие переключатели GC, которых я еще не знаю.
Я чувствую себя немного потерянным, так как я на самом деле не специалист по этой теме, и кажется, что есть много вещей, которые можно рассмотреть.
Вместо того, чтобы пытаться победить сборщик мусора, возможно, вы должны исправить утечку памяти? – Bueller
Не кажется ли более разумным исправить утечку памяти? Это похоже на капельницу под утечкой памяти. – corsiKa
Какой JVM? Какая версия? Параметры/методы настройки GC являются собственностью каждой реализации JVM. –