Milloin käytät sync-pakettia channels-asemasta?

Question

Accepted Answer

Go tarjoaa kaksi lähestymistapaa samanaikaisen suorituksen turvallisuuteen: **channels** ("jaa muistia viestinnällä") ja **`sync`-paketti** (mutexes/lukot suoraan jaetun muistin suojelemiseksi). Huolimatta Gon channels-ensimmäisen filosofian, sync-primitiivit ovat usein yksinkertaisempi ja tehokkaampi valinta jaetun tilan suojelemiseksi.

## sync.Mutex — suojaa jaettu tila lukolla

```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` varmistaa, että vain yksi goroutine pääsee kerralla suojattuihin tietoihin, mikä estää data race-kilpailuita. Kaava `Lock()`/`defer Unlock()` on idiomatiikka.

## sync.RWMutex — monet lukijat TAI yksi kirjoittaja

```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` sallii samanaikaiset luennot mutta yksinoikeudet kirjoittamiseen — ihanteellinen lukuraskaalle tiedoille, kuten välimuisteille.

## Muut sync-primitiivit

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

## Milloin käyttää sync versus 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
```

Käytännön sääntö: **"Älä viesti jakamalla muistia" on ohjenuora, ei dogmi.** Jaetun tilan yksinkertaiseen suojelemiseen mutex on selkeämpi ja tehokkaampi kuin logiikan vääntäminen channels-kanaviin.

## Miksi tämä on tärkeää

Tietää, milloin käyttää `sync`-pakettia channels-asemasta, on Go-samanaikaisen suorituksen kypsyyden avainmerkkisignaali.

Vaikka Go edistää channels-kanavia ("jaa muistia viestinnällä"), tämä on ohjenuora — ja yleinen virhe on pakottaa channels siihen, missä yksinkertainen **mutex** olisi selkeämpi ja nopeampi.

`sync`-paketti on oikea, idiomatiikan mukainen työkalu **jaetun tilan suojelemiseksi** (laskurit, välimuistit, kartat): mutexes yksinoikeusavulle, `RWMutex` lukuraskaalle tiedoille, `WaitGroup` goroutinejen odottamiseen, `Once` kertakäyttöisen alustamisen, ja `atomic`/`sync.Map` erikoistapauksille.

Ymmärrys, että channels loistavat *viestinnässä ja koordinoinnissa*, kun taas sync-primitiivit loistavat *jaetun muistin suojelemisessa* — ja sopivan työkalun valinta dogmaattisen channels-käytön sijaan — johtaa yksinkertaisempaan, tehokkaamaan ja oikeampaan samanaikaiseen koodiin.

Tämä harkinta on täsmälleen se, mikä erottaa kokeneet Go-kehittäjät, ja se on usein edistyneen tason haastattelun aihe.