பகிரப்பட்ட state-க்கான அணுகலை எவ்வாறு synchronize செய்வீர்கள்?

Question

Accepted Answer

**Synchronization** என்பது operations ஆபத்தாக ஒன்றோடொன்று கலக்காதபடி பகிரப்பட்ட mutable state-க்கு threads-இன் அணுகலை ஒருங்கிணைக்கிறது, இது **race conditions**-ஐ தடுக்கிறது. Java பல்வேறு பொறிமுறைகளை வழங்குகிறது, உள்ளமைக்கப்பட்ட `synchronized` keyword முதல் explicit locks மற்றும் lock-free 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` ஒரு நேரத்தில் ஒரே ஒரு thread மட்டுமே பாதுகாக்கப்பட்ட code-ஐ இயக்குவதை உறுதி செய்கிறது (mutual exclusion) மற்றும் **visibility**-ஐ வழங்குகிறது — ஒரு thread செய்த மாற்றங்கள் மற்றவர்களுக்குத் தெரியும் (இது memory barrier-ஐ கடக்கிறது).

## volatile — atomicity இல்லாமல் visibility

```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` ஒரு variable-இன் reads/writes threads-களுக்கு இடையே தெரியும் என்பதை உறுதி செய்கிறது — ஆனால் compound operations-ஐ (`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 locks இல்லாமல் thread-safe operations-ஐ வழங்குகின்றன — எளிய counters/accumulators-க்கு பெரும்பாலும் `synchronized`-ஐ விட வேகமானவை.

## Explicit Locks — அதிக கட்டுப்பாடு

```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`-க்கு இல்லாத features-ஐ வழங்குகிறது: `tryLock()` (non-blocking), timed waits, fairness, மற்றும் 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
```

## இது ஏன் முக்கியம்

பல threads பகிரப்பட்ட mutable state-ஐ அணுகும் போதெல்லாம் correctness-க்கு synchronization அவசியம் — அது இல்லாமல், race conditions corrupted data மற்றும் இடைப்பட்ட, கிட்டத்தட்ட-debug-செய்ய-முடியாத failures-ஐ உருவாக்குகின்றன.

கருவிகளையும் அவற்றின் துல்லியமான உத்தரவாதங்களையும் அறிவது முக்கியம்: `synchronized` (mutual exclusion + visibility), `volatile` (visibility மட்டுமே — atomicity அல்ல, ஒரு பொதுவான தவறான புரிதல்), atomic classes (எளிய ops-க்கு lock-free), மற்றும் explicit Locks (மேம்பட்ட கட்டுப்பாடு).

ஆபத்துகளைப் புரிந்துகொள்வதும் சமமாக முக்கியம் — **deadlock** மற்றும் over-synchronization செயல்திறனை பாதிப்பது — மற்றும் குறைந்தபட்சமாகவும் நிலையாகவும் synchronize செய்யும் ஒழுங்கு.

இது concurrent server-side Java-க்கான முக்கிய, அதிக-முக்கியத்துவம் வாய்ந்த அறிவு மற்றும் சரியான multithreaded code எழுதக்கூடிய developers-ஐ வேறுபடுத்தும் ஆழமான interview தலைப்பு ஆகும்.