Пример кода (классический дедлок: два мьютекса захватываются в разном порядке):

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class DeadlockExample {
private final Lock lockA = new ReentrantLock();
private final Lock lockB = new ReentrantLock();
public void task1() {
lockA.lock();
try {
// имитируем задержку, чтобы повысить шанс взаимной блокировки
Thread.sleep(50);
lockB.lock();
try {
System.out.println("Task1: got both locks");
} finally {
lockB.unlock();
}
} catch (InterruptedException ignored) {
} finally {
lockA.unlock();
}
}
public void task2() {
lockB.lock();
try {
Thread.sleep(50);
lockA.lock();
try {
System.out.println("Task2: got both locks");
} finally {
lockA.unlock();
}
} catch (InterruptedException ignored) {
} finally {
lockB.unlock();
}
}
public static void main(String[] args) {
DeadlockExample ex = new DeadlockExample();
Thread t1 = new Thread(ex::task1);
Thread t2 = new Thread(ex::task2);
t1.start();
t2.start();
}
}

Почему происходит дедлок (кратко):

Выполнены классические условия дедлока (Coffman): взаимное исключение, удержание и ожидание, отсутствие вытеснения, циклическое ожидание.Конкретно: поток (t_1) удерживает lockA и ждёт lockB, поток (t_2) удерживает lockB и ждёт lockA — образуется циклическая зависимость, поэтому оба блокируются навсегда.

Три разных подхода к устранению и оценка влияния на производительность:

1) Принудительный порядок захвата (lock ordering)

Идея: всегда захватывать локи в одном и том же порядке (например, сначала lockA, затем lockB).Влияние на производительность: накладные расходы минимальны (порядок проверки/применения конвенции) — параллелизм сохраняется максимально; сложность появляется при большем числе локов и при динамических зависимостях.Подходит, когда можно определить глобальный порядок; безопасно и дешево по CPU.

2) tryLock с таймаутом / откатом и экспоненциальным ожиданием (backoff)

Идея: вместо блокирующего lock() использовать tryLock(timeout) или tryLock() в цикле; при неудаче освобождать уже захваченные локи, ждать (возможно с рандомизацией) и пробовать снова.Влияние на производительность: предотвращает дедлок, но увеличивает накладные расходы — возможны частые повторы (CPU и задержки), временное снижение throughput при большой конкуренции; правильно настроенный backoff снижает риск livelock.Хорош для систем, где невозможно гарантировать единый порядок, и где кратковременные повторы приемлемы.

3) Сведение числа локов / грубый (coarse‑grained) lock или отказ от блокировок

Идея: заменить два локa одним общим локом (например, объединить состояние под одним synchronized/ReentrantLock), или перейти на lock‑free/immutable структуры (Atomic, Concurrent collections).Влияние на производительность: упрощает логику и полностью устраняет дедлок, но снижает параллелизм — наихудшая пропускная способность при высоком уровне конкуренции (величина снижения зависит от нагрузки). Перекладывание на lock‑free структуры может повысить масштабируемость, но увеличивает сложность реализации.Подходит, когда упрощение важнее максимальной параллельности или когда критические секции коротки.

Краткое сравнение по влиянию (обобщённо):

Порядок захвата: overhead минимален, параллелизм близок к оптимальному.tryLock+backoff: средний overhead (CPU/латентность), гибкость, риск livelock при плохой настройке.Coarse‑grained / lock‑free: либо значительное уменьшение конкуренции (при одном локе), либо улучшенная масштабируемость и сложность (при lock‑free).

Резюме: если возможно — выбрать корректный глобальный порядок локов (наиболее дешёвый и надёжный). Если порядок невозможен — использовать tryLock с таймаутом/backoff или перейти на другие структуры без блокировок, оценив компромисс между простотой и пропускной способностью.