Как вы синхронизируете доступ к общему состоянию?

Question

Accepted Answer

**Синхронизация** координирует доступ потоков к общему изменяемому состоянию так, чтобы операции не пересекались опасно, предотвращая **race conditions**. Java предлагает несколько механизмов — от встроенного ключевого слова `synchronized` до явных блокировок и lock-free атомарных операций.

## synchronized — взаимное исключение (встроенные блокировки)

```java
class BankAccount {
    private double balance;

// synchronized method — acquires the object's lock; only ONE thread at a time
    public synchronized void withdraw(double amount) {
        if (balance >= amount) {
            balance -= amount;   // protected — no interleaving
        }
    }
    // synchronized block — finer-grained, lock on a specific object
    public void deposit(double amount) {
        synchronized (this) {
            balance += amount;
        }
    }
}
```

`synchronized` гарантирует, что только один поток выполняет защищённый код одновременно (взаимное исключение) и обеспечивает **видимость** — изменения одного потока становятся видны другим (пересекает барьер памяти).

## volatile — видимость без атомарности

```java
private volatile boolean running = true;   // guarantees VISIBILITY across threads

public void stop() { running = false; }     // other threads see the change immediately
public void run() { while (running) { ... } } // without volatile, might never see false
```

`volatile` гарантирует, что чтения/записи переменной видны во всех потоках — но **НЕ** делает составные операции (такие как `count++`) атомарными. Используйте его для простых флагов, не для read-modify-write.

## Atomic классы — lock-free атомарность

```java
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();        // atomic ++ without locking (uses CPU CAS instructions)
counter.compareAndSet(5, 10);     // atomic conditional update
```

Атомарные классы обеспечивают потокобезопасные операции без блокировок — часто быстрее, чем `synchronized` для простых счётчиков/аккумуляторов.

## Явные Lock'и — больше контроля

```java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // critical section
} finally {
    lock.unlock();   // ALWAYS unlock in finally
}
// ReadWriteLock allows many concurrent readers but exclusive writers
```

`ReentrantLock` предлагает возможности, которых не хватает `synchronized`: `tryLock()` (неблокирующий), timed waits, справедливость и разделение read-write.

## Опасности, которыми нужно управлять

```text
⚠️ Deadlock — two threads each hold a lock the other needs → both stuck forever
   (avoid by always acquiring locks in a consistent order)
⚠️ Performance — over-synchronizing serializes everything, killing concurrency
   (synchronize the SMALLEST necessary section)
⚠️ Forgetting to unlock (with explicit Locks) → use try/finally
```

## Почему это важно

Синхронизация критична для корректности, когда несколько потоков обращаются к общему изменяемому состоянию — без неё race conditions приводят к повреждению данных и перемежающимся, почти невозможным для отладки сбоям.

Знание инструментов и их точных гарантий критично: `synchronized` (взаимное исключение + видимость), `volatile` (только видимость — НЕ атомарность, частое неправильное понимание), атомарные классы (lock-free для простых операций) и явные Lock'и (продвинутый контроль).

Равно важно понимать опасности — **deadlock** и чрезмерную синхронизацию, вредящую производительности — и дисциплину синхронизировать минимально и последовательно.

Это ключевое, высокорисковое знание для параллельного серверного Java и глубокая тема собеседования, которая отличает разработчиков, способных писать корректный многопоточный код.