كيف تقوم بمزامنة الوصول إلى الحالة المشتركة؟

Question

Accepted Answer

**المزامنة** تنسق وصول الخيوط (threads) إلى حالة مشتركة قابلة للتغيير بحيث لا تتداخل العمليات بشكل خطير، مما يمنع **حالات التسابق** (race conditions). توفر Java عدة آليات، بدءً من كلمة المفتاح المدمجة `synchronized` إلى الأقفال الصريحة والعمليات الذرية الخالية من الأقفال.

## synchronized — الاستبعاد المتبادل (الأقفال الداخلية)

```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` يضمن أن خيطاً واحداً فقط يقوم بتنفيذ الكود المحمي في نفس الوقت (استبعاد متبادل) ويوفر **الرؤية** (visibility) — التغييرات التي يقوم بها خيط واحد تصبح مرئية للخيوط الأخرى (حيث يعبر حاجز الذاكرة).

## volatile — الرؤية بدون الذرية

```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 — الذرية الخالية من الأقفال

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

توفر فئات Atomic عمليات آمنة للخيوط بدون أقفال — غالباً ما تكون أسرع من `synchronized` للعدادات/المراكمات البسيطة.

## الأقفال الصريحة — المزيد من التحكم

```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()` (عدم الحجب)، والانتظار المحدد بالوقت (timed waits)، والعدالة (fairness)، وفصل القراءة-الكتابة.

## الأخطار التي يجب إدارتها

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

## لماذا يهم هذا

المزامنة ضرورية للصحة كلما قام خيوط متعددة بالوصول إلى حالة مشتركة قابلة للتغيير — بدونها، تنتج حالات التسابق بيانات تالفة وأعطالاً عشوائية يكاد يكون من المستحيل تصحيحها.

معرفة الأدوات والضمانات الدقيقة لها أمر حرج: `synchronized` (استبعاد متبادل + رؤية)، `volatile` (رؤية فقط — **ليس** ذرية، سوء فهم شائع)، فئات atomic (بدون أقفال للعمليات البسيطة)، والأقفال الصريحة (تحكم متقدم).

من المهم بنفس القدر فهم الأخطار — **الجمود** (deadlock) والإفراط في المزامنة الذي يضر الأداء — والانضباط لمزامنة الحد الأدنى والمتسقة.

هذا معرفة أساسية عالية المخاطر للخوادم المتزامنة من جانب الخادم (server-side) في Java وموضوع مقابلة عميق يميز المطورين الذين يمكنهم كتابة كود متعدد الخيوط صحيح.