Kiedy używasz pakietu sync zamiast channels?

Question

Accepted Answer

Go oferuje dwa podejścia do bezpieczeństwa współbieżności: **channels** ("dzielenie pamięci poprzez komunikację") i pakiet **`sync`** (muteksy/locki do bezpośredniego ochrony współdzielonej pamięci). Pomimo "channel-first" filozofii Go'a, prymitywy sync są często prostszym i bardziej wydajnym wyborem do ochrony współdzielonego stanu.

## sync.Mutex — ochrona współdzielonego stanu za pomocą locka

```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` zapewnia, że tylko jedna goroutine ma dostęp do chronionych danych jednocześnie, zapobiegając race condition'om. Wzorzec `Lock()`/`defer Unlock()` jest idiomatyczny.

## sync.RWMutex — wielu czytelników LUB jeden pisarz

```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` pozwala na jednoczesne odczyty, ale wyłączne zapisy — idealny do danych intensywnie czytanych, takich jak cache'e.

## Inne prymitywy sync

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

## Kiedy używać 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
```

Praktyczna reguła: **"Nie komunikuj się poprzez dzielenie pamięci" to wytyczna, a nie dogmat.** Do prostej ochrony współdzielonego stanu, mutex jest jaśniejszy i bardziej wydajny niż skręcanie logiki w kanały.

## Dlaczego to ważne

Wiedzenie, kiedy używać pakietu `sync` w stosunku do channels, jest kluczowym znakiem dojrzałości w dziedzinie współbieżności w Go'ie.

Chociaż Go promuje channels ("dzielenie pamięci poprzez komunikację"), to jest wytyczna — i częstym błędem jest zmuszanie channels tam, gdzie prosty **mutex** byłby jaśniejszy i szybszy.

Pakiet `sync` jest właściwym, idiomatycznym narzędziem do **ochrony współdzielonego stanu** (liczniki, cache'e, mapy): muteksy do wyłącznego dostępu, `RWMutex` do danych intensywnie czytanych, `WaitGroup` do czekania na goroutine'y, `Once` do jednorazowej inicjalizacji, oraz `atomic`/`sync.Map` do specjalistycznych przypadków.

Rozumienie, że channels doskonale sprawdzają się w *komunikacji i koordynacji*, podczas gdy prymitywy sync doskonale sprawdzają się w *ochronie współdzielonej pamięci* — i wybór właściwego narzędzia zamiast dogmatycznego używania channels — prowadzi do prostszego, bardziej wydajnego i bardziej poprawnego kodu współbieżnego.

Ta ocena jest dokładnie tym, co odróżnia doświadczonych deweloperów Go'a i jest częstym zaawansowanym tematem rozmowy kwalifikacyjnej.