Кратко о причинах на примере:
Исходный фрагмент:
Thread t1 = new Thread(()->{ synchronized(a){ synchronized(b){}}});
Thread t2 = new Thread(()->{ synchronized(b){ synchronized(a){}}});
Что происходит (пошагово):
- Поток $t_1$ захватывает монитор ресурса $a$.
- Параллельно поток $t_2$ захватывает монитор ресурса $b$.
- $t_1$ пытается получить $b$ и блокируется (ждёт).
- $t_2$ пытается получить $a$ и блокируется.
Получилась циклическая зависимость — ни один поток не может продолжить: классический дедлок.
Необходимые условия дедлока (Coffman):
$1$ — взаимное исключение (ресурсы неразделяемы),
$2$ — удержание и ожидание (hold-and-wait),
$3$ — отсутствие принудительного вытеснения (no preemption),
$4$ — циклическое ожидание (circular wait).
Обнаружение дедлоков:
- Runtime-инструменты: jstack, jcmd, jvisualvm, jconsole, Java Mission Control — дамп потоков обычно показывает секцию "Found one Java-level deadlock".
- Программно: использовать ThreadMXBean:
- $ManagementFactory.getThreadMXBean().findDeadlockedThreads()$ — вернёт массив id потоков в дедлоке.
- Логирование/мониторинг: регулярные снимки стеков потоков, авто-анализ на циклы в графе ожиданий.
- Статический/динамический анализ: SpotBugs, статические анализаторы, тестирование на конкурренцию (jcstress, стресс-тесты), моделирование/модель-чекеры.
Стратегии предотвращения в крупной системе (практически и с учетом масштабируемости):
- Принудительный порядок захвата замков (lock ordering): каждому типу/экземпляру замка назначается уровень; всегда брать замки в порядке увеличения уровня. Очень простая и надёжная стратегия. Применимо для большинства случаев с фиксированными ресурсами.
Пример: если уровень($a$) < уровень($b$), оба потока должны захватывать сначала $a$, потом $b$.
- Использовать неблокирующие/высокоуровневые структуры: ConcurrentHashMap, Atomic* классы, LongAdder и т.п. Чем меньше явных synchronized — тем лучше.
- Избегать вложенных блокировок: реорганизовать код, чтобы операции над разными ресурсами были разнесены во времени или выполнялись атомарно одной операцией.
- Попытка с таймаутом (try-lock) и откатом: ReentrantLock.tryLock(timeout) — при неудаче освобождается всё и повторяется с backoff; полезно в распределённых/динамичных окружениях.
- Локальные/специфичные потоки (actor/queue): вынести работу с ресурсом в один поток/очередь — тогда синхронизация не нужна.
- Идемпотентность и неизменяемость: где возможно — избегать мутабельного состояния.
- Разделение и шардирование (lock striping): уменьшить конкуренцию, дать каждому шард-ресурсу свой лок.
- Централизованная политика/сервис управления блокировками в распределённой системе (например, lock manager с TTL и мониторингом).
- Мониторинг и автоперезапуск: в критичных подсистемах — обнаружение дедлока и автоматический эвент (alert, restart, эвент в оркестрации).
Конкретные исправления для фрагмента:
- Единое упорядочивание:
сделать оба потока одинаковыми по порядку:
Thread t2 = new Thread(()->{ synchronized(a){ synchronized(b){}}});
- Или использовать ReentrantLock + tryLock:
- при неуспехе — освободить ранее захваченные и повторить (backoff). Это предотвращает вечную блокировку.
- Или объединить ресурсы (если логически возможно) под один общий замок.
Рекомендации для больших систем:
- Ввести правило/политику кодирования: документированный порядок захвата замков; ревью/CI-проверки на нарушение порядка.
- Автоматический мониторинг: периодический анализ дампов с оповещением.
- Покрытие тестами: стресс- и фузз-тесты, симуляция высокой конкуренции в CI.
- Предпочитать высокоуровневые примитивы и архитектурные подходы (actor, event-driven), которые уменьшают явные блокировки.
Краткий вывод: в примере дедлок возникает из-за противоречащих порядков захвата $a$ и $b$. Простое и надёжное решение — стандартизировать порядок захвата или перейти на try-lock/высокоуровневые структуры и добавить мониторинг/тестирование для предотвращения подобных проблем в масштабе.