#java #garbage-collection
#java #сборка мусора
Вопрос:
В моей организации у нас есть правила, встроенные в планшеты Openl, в некоторых из которых более 20 условий столбцов. Это потребляет весь размер кучи Java, а затем приложение зависает. Есть предложения, что делать?
Ручная сборка мусора с использованием System.gc(), но не сработало
Исходный код доступен на планшетах OpenL
https://github.com/openl-tablets/openl-tablets/releases/tag/release-5.22.1/
Сборка мусора должна быть более эффективной и не занимать всю память, когда в столбцы условий добавляется больше условий.
Все, что превышает 20 столбцов, начинает потреблять дополнительную память, каждое редактирование, загрузка добавляют к предыдущему использованию памяти.
Мы попробовали на 32-гигабайтном сервере Linux с размером кучи java 24 ГБ, но проблема не решена
Комментарии:
1. Насколько я знаю, System.gc () неправильно запускает сборщик мусора.
Ответ №1:
Проблема, которую вы описываете, — это утечка памяти (не проблема сборщика мусора).
По какой-то причине в вашей куче находится большое количество объектов, которые не могут быть переработаны GC из-за доступности в графе объектов.
Все, что превышает 20 столбцов, начинает потреблять дополнительную память, каждое редактирование, загрузка добавляют к предыдущему использованию памяти.
Это означает, что при каждом редактировании, загрузке и т.д. Происходит утечка некоторой памяти.
Вам нужно найти причину утечки памяти, используя инструмент для анализа дампа кучи. Я могу предложить бесплатный JVisualVM и Eclipse MAT.
Я бы рекомендовал взять два дампа кучи:
- сначала после перезапуска приложения
- вторая после нескольких правок загрузка (избегайте заполнения всей памяти, работа с 20-гигабайтным дампом кучи — это боль)
В инструментах анализа дампа кучи вы можете сравнить дампы и определить, какие объекты подвергаются утечке. Этот же инструмент также позволит вам отслеживать пути от утечек экземпляров объектов до корня GC.