Мат. часть: Using JConsole to Monitor Applications
Для работы с локальным приложением:
- приложению необходимо указать jvm параметр -Dcom.sun.management.jmxremote
- запустить jconsole и подключится к выбранному приложению.
В частности, мне необходимо было найти странный затык в многопоточной программе, суть которой заключается в обработке данных из xml и записывание результата в log. Все операции ввода-вывода были помещены в mutex-блоки, и казалось бы проблем не должно было быть. Однако иногда происходило так, что cpu потреблял 100%, а размер log не менялся - новые данные не поступали.
Многопоточная модель java 5 мне нравится гораздо больше той, что была до неё, и работать гораздно удобней и приятней.
DefaultThreadFactory, которая используется в java.util.concurrent.Executors использует имена потоков вида: pool-N-thread-M - хотя безусловно можно сделать свой собственный ThreadFactory и именовать потоки так, чтобы их можно было чётко отделять от других потоков vm.
В моём же случае всё оказалось банально и просто - посмотрев по всем потокам pool-N-thread-M все, кроме одного потока ждали освобождения mutex'а, а другой банально попал в бесконечный цикл, т.к. блок кода, где данные которые добавлялись и использовались в одну и ту же map не были под mutex'ом.
И конечно же стоит ещё раз прочитать раздел Detecting Deadlocks
Словом, jconsole простой и стандартный профилировщик, которого достаточно для решения некоторых задач.
1 комментарий:
Уточнение.
JConsole -- это не совсем профайлер.
Это лишь один из JMX-клиентов (коих много, см., напр., http://mc4j.org).
Функция же профайлера (вернее, некоторые базовые функции) просто заложена в некоторых M-Bean'ах.
Можно ли создать профайлер, использующий в кач-ве "транспортного" уровня JMX и не использующий собственную agentlib -- вопрос открытый.
Для ответа на вопрос "что сейчас делается в моей JVM" JMX однозначно годится.
Для ответа на вопрос "насколько быстро что-л. делается в соей JVM" -- не знаю.
Отправить комментарий