Статические поля обычно выгружаются при отключении в WildFly?

Question

Я использую WildFly 11 Final и создал следующий EJB:

@Singleton
@Startup
public class MyDebug {
    private static final MyStaticSingleton myStaticSingleton = new MyStaticSingleton();
}

Теперь, если я повторно разверну приложение и посмотрю в кучу через JVisualVm, я увижу еще один экземпляр MyStaticSingleton для каждогоперераспределение.На экземпляры MyStaticSingleton ссылаются разные ClassLoaders.

Это нормально, что ClassLoader приложения JavaEE не удаляется после отключения приложения?

Answer 1

В спецификации EJB 3.2 (16.2.2) это ясно: вы не должны этого делать!

Корпоративный компонент не должен использовать статические поля для чтения / записи.Использование статических полей только для чтения разрешено.Поэтому, рекомендуется, чтобы все статические поля в классе корпоративного компонента были объявлены как final.

Просто используйте обычное поле для синглтона и перенесите создание в @PostConstruct.Если синглтону тоже что-то удалось, используйте инъекцию в это поле.

Answer 2

Скорее всего, у вас есть утечка, вызванная неправильным поведением вашего приложения.Это довольно распространенная проблема на самом деле.

Основная проблема заключается не в увеличении количества экземпляров вашего синглтона, а в увеличении количества загрузчиков классов и, следовательно, количества загруженных классов (которые могут быть в итоге огромными).Вы можете легко доказать это с помощью дампов javacore.

Чтобы решить эту проблему, вы должны найти объект, препятствующий сбросу каждого из этих загрузчиков классов, и, следовательно, все загруженные классы.

Один хорошо известныйПримером такого неправильного поведения приложения EE является использование log4j с включенными перехватчиками завершения работы (по умолчанию включено).

ОБНОВЛЕНИЕ

Просто для подтверждения, объект со статической ссылкой в ​​данном примере не мог вызвать упомянутые загрузчики классов / собственную утечку памяти.Более того, поскольку статическое поле объявлено как final - оно соответствует спецификации EJB.

Как упоминалось в TS, основным подозрением является пул соединений, который нарушает спецификацию EJB, выполняя собственные потоки.

Типичная причина таких утечек - использование многопоточности в среде EE, особенно вместе с контекстными загрузчиками классов.