Kuinka synkronoit pääsyn jaettuun tilaan?

Question

Accepted Answer

**Synkronointi** koordinoi säikeiden pääsyä jaettuun muutettavaan tilaan niin, että operaatiot eivät vaara vaarallisesti lomittumalla, mikä estää **kilpailutilanteita**. Java tarjoaa useita mekanismeja, sisäänrakennetusta `synchronized`-avainsanasta eksplisiittisiin lukkoihin ja lukittomiin atomisiin operaatioihin.

## synchronized — keskinäinen poissulkeminen (sisäiset lukot)

```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` varmistaa, että vain yksi säie suorittaa suojattua koodia kerrallaan (keskinäinen poissulkeminen) ja tarjoaa **näkyvyyden** — yhden säikeen tekemät muutokset tulevat näkyviksi muille (se ylittää muistin esteen).

## volatile — näkyvyys ilman atomiteettia

```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` takaa, että muuttujan lukeminen ja kirjoittaminen ovat näkyviä säikeiden välillä — mutta **EI** tee yhdistettyjä operaatioita (kuten `count++`) atomisiksi. Käytä sitä yksinkertaisille lipuille, ei luku-muokkaus-kirjoitus-operaatioille.

## Atomiset luokat — lukitton atomiteetti

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

Atomiset luokat tarjoavat säikeitä turvalliset operaatiot ilman lukkoaksia — usein nopeampia kuin `synchronized` yksinkertaisille laskureille ja akkumulaattoreille.

## Eksplisiittiset lukot — enemmän hallintaa

```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` tarjoaa ominaisuuksia, joita `synchronized` ei omaa: `tryLock()` (ei-blokaava), aikarajoittetut odotukset, oikeudenmukaisuus ja luku-kirjoitus-erottelu.

## Hallittavat vaarat

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

## Miksi se on tärkeää

Synkronointi on välttämätöntä oikeellisuuden kannalta aina, kun useita säikeitä käyttää jaettuaan muutettavaa tilaa — ilman sitä kilpailutilanteet tuottavat korruptoituja tietoja ja satunnaisia, lähes mahdottomia debugata virheitä.

Kritisesti tärkeää on tuntemaan työkalut ja niiden tarkat takuut: `synchronized` (keskinäinen poissulkeminen + näkyvyys), `volatile` (vain näkyvyys — EI atomiteetti, yleinen väärinkäsitys), atomiset luokat (lukittomat yksinkertaisille operaatioille) ja eksplisiittiset lukot (edistynyt hallinta).

Yhtä tärkeää on ymmärtää vaarat — **umpikuja** ja liiallinen synkronointi haittaa suorituskykyä — sekä kuuri synkronoida minimalistisesti ja johdonmukaisesti.

Tämä on perustieto, korkean riskin asia samanaikaisessa palvelimen puolen Javassa ja syvällinen haastattelu-aihe, joka erottaa kehittäjät, jotka voivat kirjoittaa oikein toimivaa monisäikeiset koodia.