Bilakah anda menggunakan paket sync sebagai ganti channel?

Question

Accepted Answer

Go menawarkan dua pendekatan untuk keselamatan concurrency: **channel** ("berkongsi memori dengan berkomunikasi") dan **paket `sync`** (mutex/kunci untuk melindungi memori bersama secara langsung). Meskipun filosofi channel-first Go, sync primitives sering kali merupakan pilihan yang lebih sederhana dan lebih cekap untuk melindungi keadaan bersama.

## sync.Mutex — lindungi keadaan bersama dengan kunci

```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` memastikan hanya satu goroutine yang boleh mengakses data yang dilindungi pada satu masa, mencegah perlumbaan data. Pola `Lock()`/`defer Unlock()` adalah idiomatik.

## sync.RWMutex — banyak pembaca ATAU seorang penulis

```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` membenarkan bacaan serentak tetapi penulisan eksklusif — ideal untuk data yang banyak dibaca seperti cache.

## Primitif sync lain

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

## Bilakah menggunakan sync vs channel

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

Peraturan praktikal: **"Jangan berkomunikasi dengan berkongsi memori" adalah panduan, bukan dogma.** Untuk semata-mata melindungi keadaan bersama, mutex lebih jelas dan lebih cekap daripada memutar logik ke dalam channel.

## Mengapa ini penting

Mengetahui bilakah menggunakan paket `sync` berbanding channel adalah tanda utama kematangan concurrency Go.

Sementara Go mempromosikan channel ("berkongsi memori dengan berkomunikasi"), ini adalah panduan — dan kesalahan umum adalah memaksa channel di mana **mutex** sederhana akan lebih jelas dan lebih cepat.

Paket `sync` ialah alat yang betul dan idiomatik untuk **melindungi keadaan bersama** (pembilang, cache, peta): mutex untuk akses eksklusif, `RWMutex` untuk data yang banyak dibaca, `WaitGroup` untuk menunggu goroutine, `Once` untuk inisialisasi sekali sahaja, dan `atomic`/`sync.Map` untuk kes khusus.

Memahami bahawa channel cemerlang dalam *komunikasi dan penyelarasan* manakala sync primitives cemerlang dalam *menjaga memori bersama* — dan memilih alat yang sesuai dan bukannya secara dogmatik menggunakan channel — membawa kepada kod concurrency yang lebih sederhana, lebih cekap, dan lebih betul.

Penghakiman ini adalah tepat apa yang membezakan pembangun Go yang berpengalaman dan merupakan topik temu duga maju yang kerap.