Ni lini unatumia package ya sync badala ya channels?

Question

Accepted Answer

Go inatoa njia mbili za usalama wa concurrency: **channels** ("share memory by communicating") na **package ya `sync`** (mutexes/locks za kulinda kumbukumbu inayoshirikiwa moja kwa moja). Licha ya falsafa ya Go inayopendelea channels, sync primitives mara nyingi ni chaguo rahisi zaidi na lenye ufanisi zaidi kwa kulinda hali inayoshirikiwa.

## sync.Mutex — linda hali inayoshirikiwa kwa lock

```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` huhakikisha goroutine moja tu inapata data iliyolindwa kwa wakati mmoja, ikizuia data races. Mfumo wa `Lock()`/`defer Unlock()` ni wa kiidiomatiki.

## sync.RWMutex — wasomaji wengi AU mwandishi mmoja

```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` huruhusu usomaji wa concurrent lakini uandishi wa kipekee — bora kwa data inayosomwa mara kwa mara kama caches.

## sync primitives nyingine

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

## Ni lini utumie sync dhidi ya 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
```

Kanuni ya vitendo: **"Don't communicate by sharing memory" ni mwongozo, si dogma.** Kwa kulinda tu hali inayoshirikiwa, mutex iko wazi zaidi na yenye ufanisi zaidi kuliko kupotosha mantiki kuwa channels.

## Kwa nini ni muhimu

Kujua ni lini utumie package ya `sync` dhidi ya channels ni ishara muhimu ya ukomavu wa concurrency wa Go.

Ingawa Go huhamasisha channels ("share memory by communicating"), huu ni mwongozo — na kosa la kawaida ni kulazimisha channels mahali ambapo **mutex** rahisi ingekuwa wazi zaidi na haraka zaidi.

Package ya `sync` ndio zana sahihi, ya kiidiomatiki kwa **kulinda hali inayoshirikiwa** (counters, caches, maps): mutexes kwa ufikiaji wa kipekee, `RWMutex` kwa data inayosomwa mara kwa mara, `WaitGroup` kwa kusubiri goroutines, `Once` kwa uanzishaji wa mara moja, na `atomic`/`sync.Map` kwa kesi maalum.

Kuelewa kwamba channels hufanya vizuri katika *mawasiliano na uratibu* wakati sync primitives hufanya vizuri katika *kulinda kumbukumbu inayoshirikiwa* — na kuchagua zana inayofaa badala ya kutumia channels kidogma — kunaongoza kwa code ya concurrent iliyo rahisi zaidi, yenye ufanisi zaidi, na sahihi zaidi.

Uamuzi huu ndio hasa unaowatofautisha watengenezaji wa Go wenye uzoefu na ni mada ya mara kwa mara ya juu katika mahojiano.