Исследование тупиков — Часть 3

В моих предыдущих двух блогах из этой серии, часть 1 и часть 2 , я демонстрировал, как создать кусок плохого кода, который блокируется, а затем использовал этот код, чтобы показать три способа получения дампа потока. В этом блоге я собираюсь проанализировать дамп потока, чтобы выяснить, что не так.

Обсуждение ниже относится как к классам Account и к классам DeadlockDemo из первой части этой серии, в которой содержатся полные списки кодов.

Первое, что мне нужно, это дамп потока из приложения DeadlockDemo , так как в Blue Peter говорили: «Вот тот, который я подготовил ранее».

Быстро просматривая, вы можете видеть, что этот дамп потока разделен на четыре части. Эти:

• Полный список всех потоков приложения
• Список заблокированных тем
• Небольшой стек следов заблокированных потоков
• Резюме кучи приложения

Список тем

Список потоков в пункте один выше представляет собой список всех потоков приложения и их текущего состояния. Отсюда видно, что приложение состоит из целого ряда потоков, которые можно условно разделить на две части. Во-первых, это фоновые темы. Это те, которые есть в каждом приложении, и они справляются со всеми грязными задачами, о которых нам, как прикладным программистам, обычно не нужно беспокоиться. Они имеют такие имена, как: « DestroyJavaVM », Low Memory Detector, Finalizer, Exception Catcher Thread and Concurrent Mark-Sweep GC Thread DestroyJavaVM Low Memory Detector, Finalizer, Exception Catcher Thread and Concurrent Mark-Sweep GC Thread DestroyJavaVM , DestroyJavaVM Low Memory Detector, Finalizer, Exception Catcher Thread and Concurrent Mark-Sweep GC Thread DestroyJavaVM . Во-вторых, есть потоки, которые вы или я можем создать как часть нашего кода. Обычно они имеют имена, состоящие из слова Thread за которым следует число. Например: Thread-3, Thread-6 and Thread-20.

Более подробно рассмотрев информацию, приведенную в теме 20, вы увидите, что ее можно разбить на несколько частей. Эти:

<td> Thread-20 <td> Имя потока, как описано выше. <tr> <td> prio = 5 <td> Приоритет потока. Число от 1 до 10, где 1 — самый низкий, а 10 — самый высокий приоритет. <tr> <tr> <td> tid = 7f971216c000 <td> Идентификатор потока. Уникальный номер, возвращаемый вызовом Thread.getId (). <tr> <td> nid = 0x118c73000 <td> Идентификатор собственного потока. Это соответствует платформо-зависимому идентификатору потока. <tr> <td> ожидает записи монитора [118c72000]

java.lang.Thread.State: BLOCKED (на объектном мониторе) <td> Это состояние потока; в этом случае он заблокирован. Также включена трассировка стека, в которой указано, где поток заблокирован.

Обратите внимание, что поток также может быть помечен как демон. Например:
Демон «RMI TCP Accept-0» prio = 5 tid = 7f97128fd800 nid = 0x117837000 runnable [117836000] java.lang.Thread.State: RUNNABLE
Потоки демона являются потоками фоновых задач, такими как поток RMI TCP Accept-0, перечисленный выше. Поток демона — это поток, который не препятствует выходу JVM. JVM выйдет или закроется, когда останутся только потоки демона.

Тем не менее, список потоков на самом деле не помогает отследить причину тупика, поэтому быстро продвигаться вперед …

Список тупиковых тем

Этот раздел дампа потока содержит список всех потоков, которые вовлечены в тупик.

Из приведенного выше сегмента видно, что все пять потоков блокируют экземпляры класса threads.deadlock.Account

Оставляя в стороне идентификаторы монитора и экземпляры учетной записи, вы можете видеть, что «Thread-21» ожидает «Thread-20», который ожидает «Thread-4», который, в свою очередь, ожидает «Thread-7». «Thread-7» ожидает «Thread-11», который ожидает «Thread-20»: тупиковая петля, как показано на рисунке ниже:

Следы стека тупика

Последним фрагментом головоломки является список трассировок стека заблокированных нитей, как показано ниже:

Из предыдущего раздела мы знаем, что Thread-20 через обходной маршрут ожидает Thread-11 а Thread-11 ожидает Thread-20 . Это наш тупик.

Следующий шаг — привязать этот тупик к строкам кода, используя трассировку стека потоков выше, и я упростил это на диаграмме ниже.

На приведенной выше диаграмме для ясности я удалил префикс 7f3366 из идентификаторов объектов; следовательно, объект 7f3366f58 теперь является f58 . Из этой диаграммы видно, что объект f58 заблокирован f58 Thread-20 в строке 59 и ожидает блокировки объекта e98 в строке 86. Следуя стрелкам вниз, вы можете видеть, что Thread-7 ожидает блокировки в eb0 в строке 86, которая, в свою очередь, заблокирована eb0 Thread-11 в строке 59. Thread-11 ожидает блокировки на f58 в строке 86, которая, f58 цикл, блокируется в строке 58 Thread-20 .

Итак, где эти строки кода? Ниже показана строка 59:

… а это строка 86:

Каждый иногда получает сюрпризы, и трассировка стека выше удивила меня. Я ожидал, что замки будут на линиях 85 и 86; однако они были на 59 и 86. Поскольку строка 59 не содержит синхронизированного ключевого слова, я предполагаю, что компилятор выполнил некоторую оптимизацию первого синхронизированного ключевого слова метода Transfer (…).

Из этого можно сделать вывод, что код, который случайным образом выбирает два объекта Account из списка, блокирует их в неправильном порядке в строках 59 и 86. Так в чем же проблема? Подробнее об этом в следующий раз; Тем не менее, есть один последний момент, на который следует обратить внимание: составление взаимоблокировки может быть разным при каждом создании дампа потока в программе. После повторного запуска программы DeadlockDemo и использования kill -3 PID для получения дампа другого потока я получил следующие результаты:

В этом дампе потока в тупик вовлечено меньшее количество потоков, но если вы проанализируете его, вы сможете сделать те же выводы, что и в моем первом примере.

В следующий раз: исправление кода …

Для получения дополнительной информации см. Другие блоги в этой серии.

Весь исходный код для этого и других блогов из этой серии доступен на Github по адресу: gitub.com/roghughe/captaindebug.git.

Ссылка: Исследование тупиков — Часть 3: Анализ дампа потоков от нашего партнера по JCG Роджера Хьюза в блоге Captain Debug’s Blog .