Поведение нескольких экземпляров ParallelWebAppClassLoaders в Tomcat JVM, сохраняющих объекты

Question

Я работаю над выявлением повторяющихся проблем OutOfMemory на сервере Tomcat 8.5.38 (Centos 7.6, openjdk 1.8, 4 CPU), на котором запущено приложение Spring MVC.

Эта проблема является новой для этого приложения. ( Редактировать: Проблема началась после обновления Tomcat с 8.5.35 до 8.5.38). Я сохранил дамп кучи памяти, добавив параметр JVM «-XX: + HeapDumpOnOutOfMemoryError». В дампе кучи я вижу, что есть 2 экземпляра ParallelWebAppClassLoader. Это приложение использует большой HashMap (около 200 Мб) значений поиска в качестве кэша. Каждый загрузчик классов имеет отдельную ссылку на этот HashMap. Я пытаюсь выяснить, почему в этой JVM есть 2 экземпляра ParallelWebAppClassLoader? В server.xml не указано использование ParallelWebAppClassLoader.

Также правильно ли ожидать, что ParallelWebAppClassLoader будет поддерживать копию HashMap?

Если это 2 копии одного и того же объекта, как можно оптимизировать это дублированное пространство, если используется ParallelWebAppClassLoader?

Answer 1

Проблема заключалась в обновлении Tomcat с 8.5.35 до 8.5.35. После этого обновления JVM имеет два загрузчика классов и, таким образом, занимает в два раза больше памяти. Быстро исправить это можно, увеличив ОЗУ или откатив версию Tomcat до 8.5.35.

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