Kdy používáte balíček sync místo channels?

Question

Accepted Answer

Go nabízí dva přístupy k bezpečnosti konkurence: **channels** ("sdílejte paměť komunikací") a **balíček `sync`** (mutexes/zámky pro přímou ochranu sdílené paměti). Navzdory filosofii Go zaměřené na channels jsou sync primitiva často jednoduší a efektivnější volbou pro ochranu sdíleného stavu.

## sync.Mutex — ochrana sdíleného stavu zámkem

```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` zajišťuje, že k chráněným datům může přistupovat pouze jeden goroutine najednou, čímž se zabraňuje datovým závodům. Vzor `Lock()`/`defer Unlock()` je idiomatický.

## sync.RWMutex — mnoho čtenářů NEBO jeden pisatel

```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` umožňuje souběžné čtení, ale výhradní zápis — ideální pro data s vysokou čteností, jako jsou mezipaměti.

## Další sync primitiva

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

## Kdy používat 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
```

Praktické pravidlo: **"Nekomunikujte sdílením paměti" je pokyn, ne dogma.** Pro jednoduchou ochranu sdíleného stavu je mutex jasnější a efektivnější než přetváření logiky do channels.

## Proč je to důležité

Vědět, kdy používat balíček `sync` versus channels, je klíčový znak dospělosti konkurence v Go.

I když Go propaguje channels ("sdílejte paměť komunikací"), jde o pokyn — a běžnou chybou je vynucování channels tam, kde by byl jednoduchý **mutex** jasnější a rychlejší.

Balíček `sync` je správný, idiomatický nástroj pro **ochranu sdíleného stavu** (čítače, mezipaměti, mapy): mutexes pro výhradní přístup, `RWMutex` pro data s vysokou čteností, `WaitGroup` pro čekání na goroutines, `Once` pro inicializaci jedenkrát a `atomic`/`sync.Map` pro speciální případy.

Chápání, že channels vynikají v *komunikaci a koordinaci*, zatímco sync primitiva vynikají v *ochraně sdílené paměti* — a výběr vhodného nástroje místo dogmatického používání channels — vede k jednoduššímu, efektivnějšímu a správnějšímu souběžnému kódu.

Tento úsudek je přesně to, co rozlišuje zkušené vývojáře Go, a je to často pokročilé téma v rozhovorech.