متى تستخدم حزمة sync بدلاً من channels؟

Question

Accepted Answer

يوفر Go طريقتين لأمان التزامن: **channels** ("شارك الذاكرة من خلال التواصل") و**حزمة `sync`** (mutexes/locks لحماية الذاكرة المشتركة مباشرة). على الرغم من فلسفة Go التي تفضل channels، فإن بدائل sync غالباً ما تكون الخيار الأبسط والأكثر كفاءة لحماية الحالة المشتركة.

## sync.Mutex — حماية الحالة المشتركة بقفل

```go
type Counter struct {
    mu    sync.Mutex
    count int
}

func (c *Counter) Increment() {
    c.mu.Lock()           // acquire the lock — only one goroutine at a time past here
    defer c.mu.Unlock()    // release on return (defer ensures it always happens)
    c.count++              // safe — protected critical section
}
```

يضمن `Mutex` أن goroutine واحد فقط يمكنه الوصول إلى البيانات المحمية في وقت واحد، مما يمنع سباقات البيانات. نمط `Lock()`/`defer Unlock()` هو النمط المألوف.

## sync.RWMutex — قراء متعددون أو كاتب واحد

```go
type Cache struct {
    mu   sync.RWMutex
    data map[string]string
}
func (c *Cache) Get(key string) string {
    c.mu.RLock()           // READ lock — multiple readers allowed concurrently
    defer c.mu.RUnlock()
    return c.data[key]
}
func (c *Cache) Set(key, value string) {
    c.mu.Lock()            // WRITE lock — exclusive
    defer c.mu.Unlock()
    c.data[key] = value
}
```

يسمح `RWMutex` بقراءات متزامنة لكن عمليات كتابة حصرية — مثالي للبيانات الثقيلة على القراءة مثل الذاكرات المؤقتة.

## بدائل sync أخرى

```go
sync.WaitGroup           // wait for a group of goroutines to finish (Add/Done/Wait)
sync.Once                // run something EXACTLY once (lazy init, singletons)
  var once sync.Once
  once.Do(initialize)    // initialize runs only on the first call, ever
sync.Map                 // a concurrent map (specialized cases)
atomic.AddInt64(&n, 1)   // lock-free atomic operations for simple counters
```

## متى تستخدم sync مقابل channels

```text
Use sync (Mutex/RWMutex/atomic) when:
  ✓ Protecting simple shared STATE (a counter, a cache, a map)
  ✓ The logic is "guard this data" — locking is simpler and faster than channels here
  ✓ Read-heavy data (RWMutex), one-time init (Once), simple counters (atomic)

Use channels when:
  ✓ COMMUNICATING/passing data between goroutines, signaling, coordinating
  ✓ Pipelines, worker distribution, ownership transfer
```

القاعدة العملية: **"لا تتواصل بمشاركة الذاكرة" هو توجيه وليس عقيدة.** لحماية الحالة المشتركة ببساطة، فإن mutex أوضح وأكثر كفاءة من تشويه المنطق إلى channels.

## لماذا يهم الأمر

معرفة متى تستخدم حزمة `sync` مقابل channels هي علامة رئيسية على نضج التزامن في Go.

في حين أن Go تعزز channels ("شارك الذاكرة من خلال التواصل")، هذا هو توجيه فقط — والخطأ الشائع هو فرض channels حيث يكون **mutex** بسيط أوضح وأسرع.

حزمة `sync` هي الأداة الصحيحة والمألوفة **لحماية الحالة المشتركة** (العدادات، الذاكرات المؤقتة، الخرائط): mutexes للوصول الحصري، `RWMutex` للبيانات الثقيلة على القراءة، `WaitGroup` لانتظار goroutines، `Once` للتهيئة لمرة واحدة، و`atomic`/`sync.Map` للحالات المتخصصة.

فهم أن channels تتفوق في *التواصل والتنسيق* بينما بدائل sync تتفوق في *حماية الذاكرة المشتركة* — واختيار الأداة المناسبة بدلاً من استخدام channels بعناد — يؤدي إلى كود متزامن أبسط وأكثر كفاءة وأكثر صحة.

هذا الحكم بالضبط هو ما يميز مطوري Go ذوي الخبرة وهو موضوع متقدم متكرر في المقابلات.