Si sincronizoni aksesen në gjendjen e ndarë?

Question

Accepted Answer

**Sinkronizimi** koordinon aksesen e rrjedhave në gjendjen e ndarë të ndryshueshme, në mënyrë që operacionet të mos përqafohen në mënyrë të rrezikshme, duke parandaluar **kushtet e garës**. Java ofron disa mekanizma, nga fjala kyçe e ndërtuar në `synchronized` në bllokime eksplicite dhe atomikat pa bllokime.

## synchronized — përjashtim i ndërsjelltë (bllokime të përgjithshme)

```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` siguron që vetëm një rrjedhë të ekzekutojë kodin e mbrojtur në një kohë (përjashtim i ndërsjelltë) dhe siguron **dukshmëri** — ndryshimet bërë nga një rrjedhë bëhen të dukshme për të tjerat (ajo kalon pengesën e kujtesës).

## volatile — dukshmëria pa atomicitet

```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` garanton që leximet/shkrimimet e një variabli janë të dukshme përgjatë rrjedhjeve — por NUK e bën operacionet e përbëra (si `count++`) atomike. Përdoreni atë për flamuje të thjeshta, jo për lexim-modifikim-shkrim.

## Klasat atomike — atomicitet pa bllokime

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

Klasat atomike ofrojnë operacione të sigurta për rrjedhat pa bllokime — shpesh më të shpejta se `synchronized` për numërorë/akumulatorë të thjeshtë.

## Bllokime eksplicite — më shumë kontroll

```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` ofron veçori që `synchronized` nuk ka: `tryLock()` (jo-bllokues), pritsjet me kohë, drejtësi, dhe ndarje lexim-shkrim.

## Rreziqet për të menaxhuar

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

## Pse ka rëndësi

Sinkronizimi është thelbësor për korrektësinë sa herë që rrjedha të shumta aksesojnë gjendjen e ndarë të ndryshueshme — pa të, kushtet e garës prodhojnë të dhëna të korruptuara dhe dështime gati të pamundura për t'u diagnostikuar.

Dia mjetet dhe garantimet e tyre të sakta — `synchronized` (përjashtim i ndërsjelltë + dukshmëri), `volatile` (vetëm dukshmëri — JO atomicitet, një keqkuptim i zakonshëm), klasat atomike (pa bllokime për operacione të thjeshta), dhe bllokimet eksplicite (kontroll i përparuar).

Egalisht e rëndësishme është të kuptohet rreziqet — **bllokimi i vdekjes** dhe sinkronizimi i tepërt që dëmton performancën — dhe disiplinën për të sinkronizuar minimalisht dhe në mënyrë konsistente.

Kjo është njohuri thelbësore dhe me rrezik të lartë për Java anën e serverit të njëkohshëm dhe një temë e thellë interjeje që dallon zhvillueset që mund të shkruajnë kod saktë me shumë rrjedha.