আপনি শেয়ার করা স্টেটে অ্যাক্সেস কীভাবে সিঙ্ক্রোনাইজ করেন?

Question

Accepted Answer

**Synchronization** থ্রেডগুলির শেয়ার করা মিউটেবল স্টেটে অ্যাক্সেসকে সমন্বয় করে যাতে অপারেশনগুলি বিপজ্জনকভাবে ইন্টারলিভ না হয়, **race conditions** প্রতিরোধ করে। Java বিল্ট-ইন `synchronized` কীওয়ার্ড থেকে শুরু করে 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` নিশ্চিত করে যে শুধুমাত্র একটি থ্রেড একবারে protected code এক্সিকিউট করে (mutual exclusion) এবং **visibility** প্রদান করে — এক থ্রেডের পরিবর্তন অন্যদের কাছে দৃশ্যমান হয় (এটি 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` নিশ্চিত করে যে একটি ভেরিয়েবলের reads/writes থ্রেড জুড়ে দৃশ্যমান — কিন্তু 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` যা করতে পারে না তার বৈশিষ্ট্য অফার করে: `tryLock()` (non-blocking), timed waits, fairness, এবং read-write separation।

## পরিচালনা করার বিপদ

```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 ডেটা corrupt করে এবং intermittent, nearly-impossible-to-debug failures তৈরি করে।

টুলগুলি এবং তাদের precise guarantees জানা সমালোচনামূলক: `synchronized` (mutual exclusion + visibility), `volatile` (শুধুমাত্র visibility — atomicity নয়, একটি সাধারণ ভুল বোঝাপড়া), atomic classes (সাধারণ ops এর জন্য lock-free), এবং explicit Locks (advanced control)।

সমানভাবে গুরুত্বপূর্ণ বিপদ বোঝা — **deadlock** এবং over-synchronization যা কর্মক্ষমতা হ্রাস করে — এবং ন্যূনতম এবং ধারাবাহিকভাবে synchronize করার শৃঙ্খলা।

এটি concurrent server-side Java এর জন্য মূল, উচ্চ-দাঁড়িত জ্ঞান এবং একটি গভীর ইন্টারভিউ বিষয় যা যারা সঠিক multithreaded code লিখতে পারে তাদের আলাদা করে।