Насколько рискованно использование synchronized

Риски использования synchronized

Использование synchronized — это мощный инструмент для синхронизации потоков, но он действительно несёт значительные риски, о которых нужно знать каждому Java разработчику.

Основные риски

1. Deadlock (Взаимная блокировка)

Самый опасный риск — когда два потока ждут друг друга. Классический пример:

public class Account {
    public synchronized void transfer(Account other, int amount) {
        // Поток A: захватил this.lock, ждет other.lock
        if (this.balance >= amount) {
            this.balance -= amount;
            other.deposit(amount);
        }
    }

    public synchronized void deposit(int amount) {
        this.balance += amount;
    }
}

// Использование:
Account acc1 = new Account(1000);
Account acc2 = new Account(500);

// Поток 1: acc1.transfer(acc2, 100)
// Поток 2: acc2.transfer(acc1, 50)
// → DEADLOCK! Оба потока ждут друг друга

2. Performance Degradation (Деградация производительности)

Высокая конкуренция за блокировку приводит к контекстным переключениям и кэш-мисс:

// ❌ Плохо: весь метод заблокирован
public synchronized void processLargeData(List<Data> items) {
    for (Data item : items) {
        // Долгая обработка, но блокировка держится весь этот период
        item.process();
    }
}

// ✅ Лучше: блокировка только где нужна
public void processLargeData(List<Data> items) {
    for (Data item : items) {
        item.process(); // Без блокировки
        synchronized(this) {
            addToResult(item); // Критическая секция минимальна
        }
    }
}

3. Lock Escalation и Priority Inversion

Потоки с низким приоритетом могут блокировать высокоприоритетные потоки, захватив монитор объекта.

4. Сложность отладки и тестирования

Ошибки синхронизации:

• Воспроизводятся непредсказуемо (race conditions)
• Очень сложно отловить в тестах
• Могут появляться в production под нагрузкой

// Даже это может быть проблемой:
public synchronized int getValue() {
    return value; // Если value типа int, это атомарно
}

// Но это уже проблема:
public synchronized long getValue() {
    return value; // long - НЕ атомарно без synchronized!
}

Альтернативы synchronized

1. java.util.concurrent.locks.ReentrantLock

Больше контроля, но требует try-finally:

private final Lock lock = new ReentrantLock();

public void criticalSection() {
    lock.lock();
    try {
        // Критическая секция
    } finally {
        lock.unlock(); // ОБЯЗАТЕЛЬНО!
    }
}

// С timeout:
if (lock.tryLock(10, TimeUnit.SECONDS)) {
    try {
        // Работаем
    } finally {
        lock.unlock();
    }
} else {
    System.out.println("Не смогли захватить блокировку");
}

2. ReadWriteLock для read-heavy workload

private final ReadWriteLock lock = new ReentrantReadWriteLock();

public void readData() {
    lock.readLock().lock();
    try {
        // Много читателей могут одновременно
    } finally {
        lock.readLock().unlock();
    }
}

public void writeData() {
    lock.writeLock().lock();
    try {
        // Эксклюзивный доступ
    } finally {
        lock.writeLock().unlock();
    }
}

3. Atomic классы для простых операций

private AtomicInteger counter = new AtomicInteger(0);

public void increment() {
    counter.incrementAndGet(); // Без блокировок!
}

public int getCounter() {
    return counter.get();
}

4. ConcurrentHashMap вместо Collections.synchronizedMap()

// ❌ Блокирует весь map
Map<String, Integer> map = Collections.synchronizedMap(new HashMap<>());

// ✅ Lock striping: блокирует только часть map
Map<String, Integer> map = new ConcurrentHashMap<>();

Правила безопасности при использовании synchronized

1. Всегда одинаковый порядок захвата блокировок — избежать deadlock
2. Минимизировать критическую секцию — быстрее отпустить блокировку
3. Никогда не вызывай чужой код в synchronized блоке — риск deadlock
4. Не используй synchronized на методах, которые долго работают
5. Предпочитай immutability — лучший способ избежать синхронизации

Вывод

synchronized — это инструмент прошлого поколения. Он всё ещё полезен для простых случаев, но для сложной логики лучше использовать java.util.concurrent. Главная идея: синхронизация должна быть максимально узкой и предсказуемой.