Использование Jconsole для утечки памяти - PullRequest
10 голосов
/ 15 ноября 2010

Я пытаюсь диагностировать некоторые проблемы с памятью на нашем сервере J2EE.Я установил jconsole на наш работающий сервер, и я пытаюсь отслеживать состояние сервера Tomcat через него.У меня есть быстрый вопрос о вкладке Threads в jconsole.Я могу увидеть поток с именем Finalizer в списке потоков.Число «Всего заблокировано» в этой теме продолжает расти.Например, сейчас 4049, час назад было 3867.

Name: Finalizer<br> State: WAITING on java.lang.ref.ReferenceQueue$Lock@1b79cfd<br> Total blocked: 4,049 Total waited: 1,579

Что означает эта тема?Это как-то связано с ГК?Я скачал дамп кучи, где он показывает, что число объектов, ожидающих завершения, равно нулю.

В настоящий момент максимальный размер кучи моего сервера составляет 200 МБ, размер кучи остается между 100 и 150 МБ, и когда янажмите на «Perform GC», я вижу, как освобождается некоторое пространство кучи.Однако это не меняет объем памяти, занятый этим процессом tomcat в диспетчере задач Windows, который в настоящее время потребляет более 700 МБ.

Любые советы о том, как мне поступить, будут очень благодарны.Пожалуйста, задавайте мне вопросы, если вам нужна дополнительная информация о настройке моего сервера.

Заранее спасибо.

Ответы [ 4 ]

10 голосов
/ 16 ноября 2010

Я думаю, что нашел ответ на свой вопрос. «Всего заблокированных» и «Всего ожидаемых» просто подсчитывают, сколько раз поток ожидал или был заблокирован. JConsole получает эту информацию из ThreadInfo .

Количество заблокированных - это общее количество блокировок потока для входа или повторного входа в монитор. То есть сколько раз поток находился в состоянии java.lang.Thread.State.BLOCKED.

Количество ожидающих - это общее количество раз, которое поток ожидал уведомления. то есть сколько раз поток находился в состоянии java.lang.Thread.State.WAITING или java.lang.Thread.State.TIMED_WAITING.

1 голос
/ 10 декабря 2010

Имя: Финализатор Состояние: Ожидание включено java.lang.ref.ReferenceQueue$Lock@1b79cfd Всего заблокировано: 4 049 Всего ждали: 1579

ReferenceQueue поддерживает ссылку для всех неиспользуемых объектов (ожидает завершения), другими словами, существует 4049 объектов, ожидающих сборки мусора.

При поиске утечек памяти обязательно сделайте полный сборщик мусора (или много сборок мусора, пока ничего не восстановится) перед выполнением дампа

0 голосов
/ 15 ноября 2010

Выглядит как тупик для меня: http://download.oracle.com/javase/tutorial/essential/concurrency/deadlock.html

Есть ли у вас какие-либо синхронизированные методы, которые могут бесконечно ждать?

0 голосов
/ 15 ноября 2010

Диспетчер задач Windows показывает размер виртуальной памяти и в большинстве случаев не точен. Я видел это много раз, и то, что показывает JConsole, - это правильный след памяти.

Для получения дополнительной информации о JConsole, проверьте здесь .

...