Hogyan szinkronizálja a megosztott állapot elérését?

Question

Accepted Answer

**A szinkronizáció** koordinálja a szálak hozzáférését a megosztott megváltoztatható állapothoz, hogy a műveletek ne keveredjenek meg veszélyesen, megakadályozva a **race condition** jelenségét. A Java több mechanizmust kínál, a beépített `synchronized` kulcsszótól az explicit zárakig és a lock-free atomicokig.

## synchronized — kölcsönös kizárás (intrinsic locks)

```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;
        }
    }
}
```

A `synchronized` biztosítja, hogy egy időben csak egy szál hajtsa végre a védett kódot (kölcsönös kizárás) és **láthatóságot** nyújt — egy szál módosításai a többi szál számára láthatóvá válnak (átlépi a memória korlátját).

## volatile — láthatóság atomicitás nélkül

```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
```

A `volatile` garantálja, hogy a változó olvasása/írása látható legyen a szálak között — azonban **NEM** teszi atomickáké az összetett műveletek (mint a `count++`). Használja egyszerű flagekhez, nem read-modify-write-hez.

## Atomic osztályok — lock-free atomicitate

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

Az Atomic osztályok zárak nélkül biztosítanak szálbiztos műveleteket — gyakran gyorsabbak, mint a `synchronized` egyszerű számlálók/akumulátorok esetén.

## Explicit zárak — több vezérlés

```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
```

A `ReentrantLock` olyan funkciókat kínál, amelyek a `synchronized` nem rendelkezik: `tryLock()` (nem blokkoló), időzített várakozások, igazságosság és read-write szétválasztás.

## A kezelendő veszélyek

```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
```

## Miért fontos ez

A szinkronizáció nélkülözhetetlen a helyesség szempontjából, amikor több szál megosztott megváltoztatható állapothoz fér hozzá — nélküle a race condition sérült adatokat és időszakos, szinte hibakeresésre lehetetlen hibákat okoz.

Kritikus fontosságú az eszközök és azok pontos garantálásainak ismerete: `synchronized` (kölcsönös kizárás + láthatóság), `volatile` (csak láthatóság — NEM atomicitate, gyakori félreértelmezés), atomic osztályok (lock-free egyszerű műveletek esetén) és explicit zárak (fejlett vezérlés).

Egyenlően fontos a veszélyek megértése — **deadlock** és a túlzott szinkronizáció, amely ront a teljesítményen — és az a fegyelem, hogy minimálisan és konzisztensen szinkronizáljon.

Ez alapvető, magas tétű ismerete a párhuzamos szerver oldali Java-nak és egy mély interjú témája, amely megkülönbözteti azokat a fejlesztőket, akik helyes multiszálú kódot tudnak írni.