Увеличение байтов для javaw-процесса в java 8

Мой проект начал использовать java 8 из java 7.

После перехода на java 8 мы видим, что проблемы, связанные с потреблением памяти, со временем становятся все выше.

Вот те исследования, которые мы сделали:

Проблемы возникают только после перехода из java7 и из java8
Поскольку metaspace - единственное, что связано с памятью, которая изменяется от hava 7 до java 8. Мы отслеживали metaspace, и это не увеличилось более чем на 20 МБ.
Куча также остается непротиворечивой.

Теперь единственный путь - проанализировать, как распределяется память для обработки в java 7 и java 8, в частности, в частную память байтов. Любые мысли или ссылки здесь будут оценены.

ПРИМЕЧАНИЕ. Это приложение javaw представляет собой приложение на основе swing.

ОБНОВЛЕНИЕ 1: проанализировав собственную память с помощью инструмента NMT и создав разницу в памяти, сравниваемую с базой. Мы обнаружили, что куча осталась такой же, но потоки просачивают всю эту память. Так как никаких изменений в куче, я предполагаю, что эта утечка происходит из-за собственного кода.

Так что вызов остается открытым. Любые мысли о как анализировать память, занятую всеми потоками, будут полезны здесь. Ниже приведены снимки, взятые из встроенного отслеживания памяти.

В этом рисунке вы видите, что 88 МБ увеличилось в потоках. Там, где количество рукописей и ресурсов было значительно увеличено.

на этой картинке видно, что в этом Malloc увеличилось 73 МБ. Но здесь нет имени метода.

Поэтому, пожалуйста, бросьте какую-то информацию в понимание этих скриншотов.

Ответ 1

Вы можете попробовать другую реализацию GC, такую как G1, введенную в Java 7, и вероятно, GC по умолчанию в Java 9. Для этого просто запустите свои Java-приложения с помощью:

-XX:+UseG1GC

Также есть интересная функциональность с G1 GC в Java 8u20, которая может искать дублированные строки в куче и "дедуплицировать" их (это работает только если вы активируете G1, а не по умолчанию Java 8 GC).

-XX:+UseStringDeduplication

Будьте внимательны, чтобы тщательно протестировать вашу систему перед тем, как перейти к производству с таким изменением!!!

Здесь вы можете найти хорошее описание различных GC, которые вы можете использовать

Ответ 2

рассмотрим оптимизацию параметров JVM

Параллельный коллектор (пропускной коллектор)

-XX: + UseParallelGC
параллельные коллекторы (коллекторы с малой задержкой)

-XX: + UseConcMarkSweepGC
использовать String Duplicates remover

-XX: + UseStringDeduplication
оптимизировать компактное соотношение

-XXcompactRatio: и см. link1 link2

Ответ 3

В этом моем ответе вы можете увидеть информацию и ссылки, как профилировать собственную память JVM, чтобы найти утечки памяти. В ближайшее время см. this.

UPDATE

Вы использовали параметр -XX: NativeMemoryTracking = detail? Результаты просты, они показывают, что большая часть памяти выделяется malloc.:) Это немного очевидно. Ваш следующий шаг - профилировать ваше приложение. Для анализа собственных методов и Java я использую (и использую на производстве) пламенные графики с perf_events. Посмотрите на это сообщение в блоге для хорошего старта.

Обратите внимание, что ваша память увеличилась для потоков, вероятно, ваши потоки растут в приложении. Перед первичным я рекомендую проанализировать потоки дампов до/после, чтобы проверить, растет ли число потоков Java и почему. Сбрасывать потоки вы можете с помощью jstack/jvisualvm/jmc и т.д.