Утечка памяти без увеличения количества или размера объектов
В системе IBM iSeries у меня запущена программа Java - сервер приложений с компонентом веб-сервера, все это разработано собственными силами. при работе на 32-разрядной или 64-разрядной J9 JVM (IBM Technology for Java) у меня наблюдаются симптомы утечки памяти.
Обратите внимание, что никаких проблем при запуске этого программного обеспечения на классической JVM iSeries, на нескольких JVM Sun / Oracle и на других платформах не наблюдается. Linux JVM. Черт возьми, я обычно оставляю идентичное программное обеспечение работающим на несколько недель на ноутбуке начального уровня моей жены, пока я работаю над своим веб-сайтом - я могу вас заверить, что если бы происходила утечка памяти, это было бы замечено на этой штуке.
Если я просто оставлю обычную систему, работающую в режиме ожидания, без настроенных приложений (в основном, только система обмена сообщениями и веб-сервер), куча просто продолжит медленно расти, в результате чего со временем будет выделяться больше памяти, с каждым Цикл GC не совсем возвращается к предыдущему уровню. Шаблон точно такой же для JVM, где нет проблем, за исключением того, что на них очистка GC всегда уменьшает кучу до ее предыдущего уровня GC.
Но, если я получаю системный дамп JVM при запуске после стабилизации и последующие дампы после того, как выделенная куча значительно увеличилась, дифференциальное сравнение показывает, что после работы в течение недели объектов больше нет, чем было при запуске. Самый последний, через неделю, показывает 6 загруженных дополнительных классов и несколько объектов, явно связанных с ними. Тщательные обзоры всех живых объектов не показали ничего неожиданного.
Я пробовал использовать сборщики мусора, оптимизированные для пропускной способности, и сборщики мусора, работающие одновременно с поколениями.
Таким образом, согласно размеру кучи задания, утечка происходит, а согласно дампу кучи ничего не происходит.
Не вызываются никакие методы JNI (кроме собственного кода, работающего как часть ядра JVM), и определенно растет куча - я ясно вижу это в информации IBM WRKJVMJOB, а также в сообщениях с использованием JMX-бинов. в моем файле журнала консоли.
Пока я не могу подключиться к активной JVM с помощью инструментов JMX, таких как JVisualVM, потому что, хотя прослушивающий сокет создается при правильной настройке, соединение отклоняется, очевидно на уровне протокола (стек TCP / IP показывает принятый соединение, но JVM его отклоняет).
Я сбит с толку и не знаю, куда идти дальше.
РЕДАКТИРОВАТЬ: Просто чтобы прояснить; все эти результаты получены с неинструментированной JVM, потому что я не могу получить JMX-доступ к этой JVM (мы работаем над этим с IBM).
РЕДАКТИРОВАТЬ 2011-11-16 19:27: Мне удалось получить отчет о работе сборщика мусора за 1823 цикла сборщика мусора, который включает конкретные подсчеты для подсчетов Soft / Weak / PhantomReference; нет никаких признаков стремительного роста этих чисел. Тем не менее, наблюдается значительный рост жилого пространства для малых объектов (жилое пространство для больших объектов пусто). Он вырос с 9 млн до 36 млн.