Kapan sampeyan nggunakake paket sync tinimbang channel?

Question

Accepted Answer

Go menawarake rong pendekatan kanggo keamanan concurrency: **channel** ("melu-melu memori kanthi komunikasi") lan **paket `sync`** (mutex/lock kanggo nglindhungi memori sing didungakake langsung). Senadyan filosofi channel-first Go, primitif sync asring dadi pilihan sing luwih prasaja lan efisien kanggo nglindhungi status sing didungakake.

## sync.Mutex — lindhungi status sing didungakake kanthi 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 mesthine mung siji goroutine bisa ngakses data sing dilindungi ing sawijining wektu, nyegah data race. Pola `Lock()`/`defer Unlock()` iku idiomatis.

## sync.RWMutex — akeh pembaca UTAWA siji panulis

```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` ngidini wacan concurrent nanging ekslusif nulis — ideal kanggo data sing akeh dibaca kaya cache.

## Primitif sync liyane

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

Paugeran praktis: **"Aja ngomunikasi kanthi melu-melu memori" minangka guideline, dudu dogma.** Kanggo mung nglindhungi status sing didungakake, mutex luwih jelas lan luwih efisien tinimbang mangkak logika menyang channel.

## Alasan iku penting

Mangerteni kapan kudu nggunakake paket `sync` lawan channel iku tandha kunci saka kematangan concurrency Go.

Dene Go promosi channel ("melu-melu memori kanthi komunikasi"), iki minangka guideline — lan kesalahan umum iku paksa channel ing ngendi **mutex** prasaja bakal luwih jelas lan cepet.

Paket `sync` iku alat sing bener lan idiomatis kanggo **nglindhungi status sing didungakake** (counter, cache, map): mutex kanggo akses ekslusif, `RWMutex` kanggo data akeh bacaan, `WaitGroup` kanggo nunggu goroutine, `Once` kanggo inisialisasi sapisan, lan `atomic`/`sync.Map` kanggo kasus sing khusus.

Mangerteni yen channel luwih apik ing *komunikasi lan koordinasi* dene primitif sync luwih apik ing *nglindungi memori sing didungakake* — lan milih alat sing cocog tinimbang dogmatis nggunakake channel — luwih ndadak menyang kode concurrent sing luwih prasaja, luwih efisien, lan luwih bener.

Paham iki persis apa sing nggabungake pangembang Go sing berpengalaman lan iki topik interview maju sing asring.