Возможности профилирования поведения параллельных программ в Java

В настоящее время есть некоторые профилировщики, которые обещают профилировать параллельное поведение выполнения программы, чтобы понять многопоточное выполнение.

Я собираю функции, которые были бы полезны для профилировщика Java, сосредоточенного только на профилировании параллелизма:

Что я собрал на данный момент:

  • построение графиков ожидания для выявления потенциальных тупиковых ситуаций

  • измерение времени доступа к ресурсам (структурам данных и т. д.)

  • показать состояния каждого потока (активен, прерван, мертв)

  • какой поток вызвал какой поток для доступа к общим ресурсам (ожидание, блокировка и т. д.)

Какие идеи у вас есть? Лично я стремлюсь выявить некоторые вредные привычки программирования при работе с параллелизмом в Java.


java thread-safety concurrency profiler jvmti
person BrokenClockwork    schedule 17.02.2011    source источник
comment
YourKit имеет некоторые из этих функций. Для других функций я добавляю код для измерения таймингов и отчета, какой поток ожидает другого и что он делает. (Таким образом, я могу запустить его в производство)   -  person Peter Lawrey    schedule 17.02.2011

Ответы (4)


arrow_upward
1
arrow_downward

Сводная статистика для каждого потока: сколько времени вы проводите в каждом состоянии (запущено, выполняется, заблокировано и т. Д.).

person NPE    schedule 17.02.2011

arrow_upward
0
arrow_downward

Инструменты для обнаружения "горячих" мониторов, чтобы определить, где находится конфликт. Например, показывать блокировки, отсортированные по общему времени, затраченному на их ожидание, с возможностью видеть биты кода, которые удерживали блокировку, и биты кода, которые ее ждали.

person NPE    schedule 17.02.2011

arrow_upward
0
arrow_downward

Любой

  • Конфликтный монитор или блокировка
  • Неудачный CAS
  • Изменчивые чтения и записи

Что было бы фантастическим, так это способ увидеть общие данные, которые не были защищены случаем раньше и поэтому были непростыми. Хотя сделать это сложно.

person Jed Wesley-Smith    schedule 18.02.2011

arrow_upward
0
arrow_downward

Когда каждый поток заблокирован, если код потока вообще сложен, простое знание того, что он заблокирован, не будет очень информативным, даже если вы можете сказать, какой другой поток он ожидает. Я хотел бы знать, почему он заблокирован.

Способ узнать почему заблокирован - это захватить стек вызовов в тот момент, когда он становится заблокированным. Каждый сайт вызова функции в стеке дает одно звено в цепочке рассуждений о том, почему он здесь.

person Mike Dunlavey    schedule 18.02.2011
comment
Спасибо, это очень полезный совет! - person BrokenClockwork; 18.02.2011