Меня попросили проанализировать дамп кучи, вызванный нехваткой памяти в среде. В проекте используется модуль веб-сокетов Grizzly 2.4.4.
Проблема заключается в том, что при высокой нагрузке (соединения с веб-сокетом) - когда соединения часто создаются и закрываются - старые закрытые соединения не собираются сборщиком мусора и вызывают утечку памяти.
В дампе кучи I заметил один и тот же шаблон для всех этих закрытых веб-сокетов - они как-то упоминаются живым (подключенным) веб-сокетом (начиная с G C root) через его индексированные атрибуты protocolHandler-> filterChainContext-> TcpNIOConnection.
Это выглядит как цепочка:
connected_websocket -> protocolHandler-> filterChainContext-> tcpNioConnection-> attribute-> websocketHolder -> old_closed_websocket -> ... .
Глядя на код, я не понял, как это на самом деле возможно - не должны ли экземпляры TcpNIOConnection быть независимыми и не ссылаться друг на друга?
Вот скриншот из дампа кучи, который более Пояснение: 
Обратите внимание на EmsWebSocket (он расширяет DefaultWebSocket - ничего особенного в нем) внизу. Это подключенная веб-розетка. И это относится к нескольким держателям веб-сокетов и TcpNIOConnections подряд, которые все закрыты. Как это вообще возможно воспроизвести? Я пробовал локально, но безуспешно.
Было бы здорово, если бы кто-то из разработчиков гризли мог прокомментировать это.
Заранее спасибо,