તમે વહેંચાયેલ સ્થિતિ માટે অ্যাक્সেસ કેવી રીતે સમન્વય કરો છો?

Question

Accepted Answer

**Synchronization** એ થ્રેડ્સ ની વહેંચાયેલ વધુપણીય સ્થિતિ માટેનું પ્રવેશ સમન્વય કરે છે જેથી ક્રિયાઓ ખતરનાક રીતે એક બીજાને વાધે નહીં, **race conditions** ને રોકે છે। Java એ બીલ્ટ-ઇન `synchronized` કીવર્ડ થી પાછળ સુધી સ્પષ્ટ લૉક્સ અને લૉક-ફ્રી atomics માટે અનેક મેકાનિઝમ આપે છે।

## synchronized — mutual exclusion (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;
        }
    }
}
```

`synchronized` સુનિશ્ચિત કરે છે કે માત્ર એક જ થ્રેડ સંરક્ષિત કોડ એક સમયે ચલાવે (mutual exclusion) અને **visibility** આપે છે — એક થ્રેડ દ્વારા કરેલા પરિવર્તનો બીજા થ્રેડને દેખાય (તે memory barrier ને પાર કરે છે)।

## volatile — visibility without atomicity

```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++`) atomic બનાય નહીં. તેને સરળ flags માટે વાપરો, read-modify-write માટે નહીં।

## Atomic classes — lock-free atomicity

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

Atomic classes લૉક્સ વીના thread-safe ક્રિયાઓ આપે છે — ઘણીવાર `synchronized` કરતા સરળ counters/accumulators માટે ઝડપી.

## Explicit Locks — more control

```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()` (non-blocking), timed waits, fairness, અને read-write separation.

## The dangers to manage

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

## શા માટે તે મહત્વપૂર્ણ છે

Synchronization હંમેશાં જરૂરી છે જ્યારે મલ્ટીપલ થ્રેડ્સ વહેંચાયેલ વધુપણીય સ્થિતિ પર પ્રવેશ કરે — તે વીના, race conditions ખરાબ ડેટા અને intermittent, લગભગ debug કરવાના અશક્ય નિષ્ફળતા ઉત્પાદન કરે છે।

ટૂલ્સ અને તેમની ચોક્કસ ગેરંટીજ જાણવી critical છે: `synchronized` (mutual exclusion + visibility), `volatile` (visibility માત્ર — atomicity નહીં, સામાન્ય ગણતરી), atomic classes (simple ops માટે lock-free) અને explicit Locks (advanced control)।

સમાન મહત્વપૂર્ણ છે dangers ને સમજવું — **deadlock** અને over-synchronization performance નુકસાન કરે છે — અને ન્યૂનતમ અને સુસંગત રીતે synchronize કરવાની discipline.

યે concurrent server-side Java માટે core, high-stakes જ્ઞાન છે અને એક ગહન interview topic છે જે developers ને અલગ પાડે છે જે સાચી multithreaded code લખી શકે છે.