Как всегда, длинное описание проблемы.

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

Профилирование приложения показывает очень большое количество объектов Finalizer, заполняющих кучу. Ну, мы подумали, что "может быть странным потоком финализатора для замедления" выпускать и проверять для уменьшения количества объектов, которые должны быть завершены (в этом случае обрабатываются нативные JNA). В любом случае, это хорошая идея и тысячи новых объектов ...

Следующие тесты показали ту же картину, только через час и не так круто. На этот раз финализаторы возникли из потоков FileInput и FileOutput, которые интенсивно используются на испытательном стенде. Все ресурсы закрыты, но финализаторы больше не очищаются.

Я понятия не имею, почему через 1 или 2 часа (без исключений) FinalizerThread внезапно перестает работать. Если мы вручную запустим System.runFinalization () в некоторых из наших потоков, профилировщик покажет, что финализаторы очищены. Возобновление теста немедленно вызывает новое выделение кучи для финализаторов.

FinalizerThread все еще там, спрашивая jConsole, что он ждет.

РЕДАКТИРОВАТЬ

Во-первых, проверка кучи с помощью HeapAnalyzer не выявила ничего нового / странного. У HeapAnalyzer есть несколько приятных функций, но сначала у меня возникли трудности. Я использую jProfiler, который поставляется с хорошими инструментами проверки кучи и останется с ним.

Может быть, мне не хватает некоторых убойных функций в HeapAnalyzer?

Во-вторых, сегодня мы настроили тесты с отладочным соединением вместо профилировщика - система стабильна уже почти 5 часов. Кажется, это очень странная комбинация слишком большого количества финализаторов (которые были сокращены в первом обзоре), профилировщика и стратегий виртуальных машин GC. Поскольку в настоящий момент все идет хорошо, никаких реальных идей ...

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