Почему возникает дедлок (коротко)
- Сценарий: поток T1 делает `synchronized(a){ synchronized(b){...}}`, поток T2 — `synchronized(b){ synchronized(a){...}}`. Если T1 успевает захватить `a`, а T2 — `b`, то каждый ждёт освобождения другого ресурса ⇒ взаимная блокировка.
- Формально срабатывают 4 условия Коффмана: взаимное исключение, удержание и ожидание, отсутствие вытеснения, циклическое ожидание.
Как распознать (быстро)
- В логах — оба потока виснут в монитор-ожидании на разных объектах.
- Инструменты: `jstack`, `jcmd Thread.print`, или программно через `ThreadMXBean.findDeadlockedThreads()`.
Стратегии предотвращения (с пояснениями)
1) Упорядочивание захвата (рекомендуется)
- Назначьте каждому ресурсу устойчивый порядок и всегда берите блокировки в этом порядке. Например, если у объектов есть id, всегда захватывайте сначала тот, у которого $id(a)<id(b)$.
- Пример-паттерн:
- присвоить каждому lock объекту уникальный числовой id;
- перед захватом выбрать `first` и `second` по сравнению id и делать `synchronized(first){ synchronized(second){...}}`.
- Надёжно и дешево по производительности.
2) Использовать Lock.tryLock с таймаутом и откатом
- Вместо `synchronized` применять `ReentrantLock` и `tryLock(timeout, unit)`. Если не удалось получить вторую блокировку — отпустить первую, подождать/backoff и повторить.
- Позволяет избежать вечной блокировки, но требует корректной логики повторов/отката.
3) Избежать одновременного удержания нескольких блокировок
- Рефакторинг: пересмотреть дизайн, чтобы не держать две блокировки одновременно (копировать данные, делать локальную immutable-снимок, применять copy-on-write).
- Часто снижает вероятность ошибок.
4) Использовать высокоуровневые concurrent-структуры
- `ConcurrentHashMap`, `Atomic*`, `StampedLock`, `java.util.concurrent` — часто позволяют обойти необходимость ручных вложенных мониторных блокировок.
5) Централизованный/единый замок
- Если объекты логически связаны, использовать один общий lock вместо нескольких мелких (простое, но может ухудшить параллелизм).
6) Детекция и аварийное восстановление
- Периодическая проверка `ThreadMXBean.findDeadlockedThreads()` + логирование стеков и эвентуальное рестартование/перезапуск затронутых задач.
Практические советы
- Предпочитайте явные `Lock` когда нужна политика таймаутов/раннего выхода.
- Документируйте порядок захвата блокировок в кодовой базе.
- Для сложных структур назначайте статический/фиксированный порядок (уникальный id), не полагайтесь на `System.identityHashCode` без обработки редких коллизий.
- Профилируйте и тестируйте с нагрузкой (ставьте искусственные задержки, чтобы воспроизвести гонки/дедлоки).
Краткий итог
- Причина: циклическое ожидание при разных порядках захвата. Простое, надёжное решение — единый детерминированный порядок захвата (или использование `tryLock` с таймаутом / рефакторинг, чтобы не держать несколько блокировок).