Мы запускаем наше приложение в Wildfly 14.0.1, с -Xmx 4096, работающее с OpenJDK 11.0.2. Я использовал VisualVM 1.4.2 для мониторинга нашей кучи, так как ранее у нас были исключения OOM (потому что наш -Xmx был только 512, что было невероятно плохо).
Несмотря на то, что сейчас мы располагаем достаточным распределением памяти, у нас больше не происходит исключений OOM, и даже при большом количестве клиентов и обработки мы не приближаемся к -Xmx4096 (серверы имеют 16 ГБ, поэтому память не проблема), я вижу странное поведение кучи, которое я не могу понять, откуда оно.
Используя VisualVM, Eclipse MemoryAnalyzer, а также heaphero.io, я получаю сводки, подобные следующим:
Всего байт: 460,447,623
Всего классов: 35 708
Всего экземпляров: 2 660 155
Загрузчики классов: 1 087
GC Корни: 4200
Количество объектов, ожидающих завершения: 0
Однако, наблюдая за монитором кучи, я вижу, что использованная куча за 4-минутный период времени увеличивается примерно на 450 МБ, прежде чем ГХ запускается и опускается обратно только для повторного всплеска. Вот изображение: 
Это когда клиенты не подключены и в нашем приложении ничего не происходит. Мы используем Apache File IO для мониторинга удаленных каталогов, у нас есть темы JMS и т. Д., Поэтому приложение не совсем бездействует, но ведется нулевое ведение журнала и все такое.
Моими самыми большими объектами являются хорошо известные io.netty.buffer.PoolChunk, которые в дампах кучи занимают около 60% моего использования памяти, общий объем все еще составляет около 460 МБ, поэтому я не понимаю, почему монитор кучи собирается от ~ 425 МБ до ~ 900 МБ несколько раз, и независимо от того, где я делаю свои снимки, я не вижу большого увеличения количества объектов или использования памяти.
Я просто вижу разрыв между монитором кучи и анализом .hprof. Таким образом, нет способа определить причину, по которой куча достигает максимума в 900 МБ.
Мой вопрос заключается в том, ожидаются ли эти пики кучи при работе в Wildfly, или в нашем приложении есть что-то, что раскручивает кучу объектов, которые затем получают GC'd? При создании отчета о компонентах объекты в структуре пакета нашего приложения составляют чрезвычайно малый объем дампа. Что нас не очищает, мы легко могли бы звонить, не закрываясь соответствующим образом и т. Д.