#java #multithreading #deadlock #jvmti
#java #многопоточность #взаимоблокировка #jvmti
Вопрос:
Интересно, возможно ли динамически обнаруживать взаимоблокировки в Java с помощью JVMTI. Есть два события, указывающие на действия на мониторах с использованием инструкции synchronized:
Монитор утверждал, что ввод
Отправляется, когда поток пытается войти в монитор языка программирования Java, уже полученный другим потоком.
Утвержденный монитор введен
Отправляется, когда поток входит в монитор языка программирования Java после ожидания его освобождения другим потоком.
Это означает, что с помощью JVMTI я могу видеть только те мониторы, которые уже заблокированы. Я хотел восстановить график ожидания, но без событий, указывающих мне, что была получена блокировка, которая не удерживается ни одним потоком. Это невозможно.
Есть ли альтернативы? Команда SIGQUIT в Unix разрешает дамп потока, который отображает взаимоблокировки, похоже, что это невозможно в JVMTI.
Ответ №1:
Вы должны иметь возможность получать эту информацию через JMX.
Попробуйте
ManagementFactory.getThreadMXBean().findMonitorDeadlockedThreads();
Комментарии:
1. Да, но при этом использовался бы агент java, а не собственный агент.
2. Вы можете вызвать Java-код из собственного кода. Я не понимаю, в чем проблема.
3. Я не думал, что собственные агенты используют байтовый код, я думал, что они написаны на C.
4. Они есть, так могу ли я использовать JNI для выполнения вызовов методов Java, подобных описанным здесь? journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing /…
5. Правильно, все, что вы можете сделать в агенте Java, вы можете сделать в собственном агенте и наоборот с помощью JNI. 😉 В качестве причудливого примера приведен File.length(), который является собственным методом, но первое, что он делает, это преобразует кодировку символов имени файла в Java через JNI. 😛