Лучшая практика для обработки утечек памяти в больших проектах Java?
4 ответа
Предположим, что вы решили решить проблему, отследив ее первопричину (утечки памяти), как бы вы собрали данные, чтобы увеличить масштаб проблемы?
Сделайте дамп кучи с помощью jmap и загрузите его с помощью Eclipse Memory Analyzer. Оттуда вы сможете проанализировать, какие объекты съедают больше всего памяти, какие "корни" мешают другим объектам и т.д.
Существуют и другие программы анализа кучи, такие как jhat, но я нашел EMA самым быстрым и лучшим (бесплатным) решением.
Предположим, что вы выбрали быстрый и грязный способ ускорения работы, просто перезапустив контейнер, как бы вы собирали данные для выбора оптимального цикла перезапуска?
Используйте JMX для мониторинга размера кучи и другой статистики кучи и GC.
Удавалось ли вам развертывать и запускать проекты в течение длительного периода времени без перезапуска контейнера сервлетов для восстановления работоспособности?
Да. Благодаря предотвращению/исправлению утечек памяти.
даже если в вашем коде нет реальных проблем, возможны утечки памяти, если вы используете apache. посетите http://www.tomcatexpert.com/blog/2010/04/06/tomcats-new-memory-leak-prevention-and-detection для получения советов и предложений
Есть несколько отличных инструментов профилирования. Научитесь использовать его регулярно и разберитесь с выводом распределения памяти.
Обычно вы следуете этому процессу для каждой важной функции вашего приложения:
- Выполните процесс один раз
- GC дважды
- Отметьте текущее количество выделенных ресурсов для всех объектов
- снова выполните ваш процесс
- GC дважды
- Отметить еще раз
- Различить две отметки
Если они не очень близки, вероятно, у вас утечка.
Если количество объектов увеличивается на заданную величину на каждой итерации этого процесса, то у вас абсолютная утечка.
В идеале вам не нужно перезапускать программу или сервлет.
Мой опыт показывает, что большинство причин проблем с памятью обычно возникает из-за проблем с распределением или объединением небольшого набора классов.
Такой инструмент, как VisualVM, отлично подходит для этого, поскольку вы можете выяснить, где находится основная тяжесть выделения вашего объекта.
С tomcat, вероятно, немного сложнее, так как вы также будете следить за фреймворком, но при достаточной осторожности и терпении вы часто можете идентифицировать горячие точки в своей логике.