Kapan Anda menggunakan paket sync alih-alih channels?

Question

Accepted Answer

Go menawarkan dua pendekatan untuk keamanan concurrency: **channels** ("share memory by communicating") dan **paket `sync`** (mutexes/locks untuk melindungi memori bersama secara langsung). Meskipun filosofi Go yang channel-first, sync primitives sering kali merupakan pilihan yang lebih sederhana dan efisien untuk melindungi shared state.

## sync.Mutex — lindungi shared state dengan 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
}
```

Satu `Mutex` memastikan hanya satu goroutine mengakses data yang dilindungi pada satu waktu, mencegah data races. Pola `Lock()`/`defer Unlock()` adalah idiomatic.

## sync.RWMutex — banyak readers ATAU satu writer

```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` memungkinkan concurrent reads tetapi exclusive writes — ideal untuk data read-heavy seperti caches.

## Sync primitives lainnya

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

## Kapan menggunakan sync vs 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
```

Praktis rule: **"Jangan komunikasikan dengan sharing memori" adalah guidelines, bukan dogma.** Untuk hanya melindungi shared state, mutex lebih jelas dan lebih efisien daripada memaksa logic ke channels.

## Mengapa ini penting

Mengetahui kapan menggunakan paket `sync` versus channels adalah tanda kunci dari maturity concurrency Go.

Meskipun Go mempromosikan channels ("share memory by communicating"), ini adalah guidelines — dan kesalahan umum adalah memaksa channels di mana sebuah **mutex** sederhana akan lebih jelas dan lebih cepat.

Paket `sync` adalah tool yang tepat dan idiomatic untuk **melindungi shared state** (counters, caches, maps): mutexes untuk exclusive access, `RWMutex` untuk data read-heavy, `WaitGroup` untuk waiting pada goroutines, `Once` untuk one-time initialization, dan `atomic`/`sync.Map` untuk specialized cases.

Memahami bahwa channels excel di *communication dan coordination* sementara sync primitives excel di *guarding shared memory* — dan memilih tool yang appropriate daripada secara dogmatik menggunakan channels — mengarah ke concurrent code yang lebih sederhana, lebih efisien, dan lebih correct.

Judgment ini tepat yang membedakan experienced Go developers dan adalah frequent advanced interview topic.