Как обнаружить и удалить (во время сеанса) неиспользуемые бины @ViewScoped, которые нельзя собрать мусором

РЕДАКТИРОВАТЬ: Проблема, поднятая этим вопросом, очень хорошо объяснена и подтверждена в этой статье codebulb.ch, включая некоторое сравнение между JSF@ViewScopedCDI@ViewSCopedи Omnifaces@ViewScopedи четкое утверждение, что JSF@ViewScoped «утечка по конструкции»:24 мая 2015 г. Области применения Java EE 7 Bean сравнили часть 2 из 2

РЕДАКТИРОВАТЬ: 2017-12-05 Тестовый пример, используемый для этого вопроса, по-прежнему чрезвычайно полезен, однако выводы, касающиеся сбора мусора в исходном посте (и изображениях), были основаны на JVisualVM, и с тех пор я обнаружил, что они недействительны.Используйте вместо этого Профилировщик NetBeans! Теперь я получаю полностью согласующиеся результаты для OmniFaces ViewScoped с тестовым приложением по принудительной установке GC из средства профилирования NetBeans вместо JVisualVM, подключенного к GlassFish / Payara, где я получаю ссылки, которые все еще хранятся (даже после вызова @PreDestroy) по полюsessionListeners типаcom.sun.web.server.WebContainerListener вContainerBase$ContainerBackgroundProcessor, и они не будут GC.

Известно, что в JSF2.2 для страницы, использующей bean-компонент @ViewScoped, переход от него (или перезагрузка) с использованием любого из следующих методов приведет к тому, что bean-компонент @ViewScoped будет «зависать» в сеансе, поэтому что это не будет сборщик мусора, что приведет к бесконечно растущей куче памяти (если это спровоцировано GET):

Используя ссылку h: для получения новой страницы.

Использование h: outputLink (или тега HTML A) для получения новой страницы.

Перезагрузите страницу в браузере, используя команду или кнопку RELOAD.

Перезагрузка страницы с помощью клавиатуры ENTER на URL браузера (также GET).

Напротив, прохождение через систему навигации JSF с помощью, скажем, h: commandButton приводит к освобождению компонента @ViewScoped, так что он может быть собран мусором.

Это объясняется (BalusC) вJSF 2.1 ViewScopedBean @PreDestroy метод не вызывается и продемонстрировано для JSF2.2 и Mojarra 2.2.9 моим небольшим примером проекта NetBeans наhttps://stackoverflow.com/a/30410401/679457, который проект иллюстрирует различные варианты навигации и являетсядоступно для скачивания здесь. (РЕДАКТИРОВАТЬ: 2015-05-28: полный код теперь также доступен здесь ниже.)

[EDIT: 2016-11-13 В настоящее время существует также улучшенное тестовое веб-приложение с подробными инструкциями и сравнением с OmniFaces.@ViewScoped и таблица результатов на GitHub здесь:https://github.com/webelcomau/JSFviewScopedNav]

Я повторяю здесь изображение index.html, которое суммирует случаи навигации и результаты для кучи памяти:

Q: Как я могу обнаружить такие "зависания / зависания" бинов @ViewScoped, вызванные GET-навигацией, и удалить их, или иначе сделать их сборщиком мусора?

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

Ответы на вопрос(2)

Ваш ответ на вопрос