Când utilizezi pachetul sync în loc de channels?

Question

Accepted Answer

Go oferă două abordări pentru siguranța concurenței: **channels** ("share memory by communicating") și pachetul **`sync`** (mutexuri/locks pentru protejarea directă a memoriei shared). În ciuda filosofiei channel-first a Go, primitivele din sync sunt adesea alegerea mai simplă și mai eficientă pentru protejarea stării shared.

## sync.Mutex — protejează starea shared cu un 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
}
```

Un `Mutex` asigură că doar o goroutine accesează datele protejate la un moment dat, prevenind race conditions. Modelul `Lock()`/`defer Unlock()` este idiomativ.

## sync.RWMutex — mulți cititori SAU un scriitor

```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` permite citiri concurente dar scrieri exclusive — ideal pentru date read-heavy cum ar fi cachele.

## Alte primitive 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
```

## Când să utilizezi 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
```

Regula practică: **"Nu comunica prin partajarea memoriei" este o ghidă, nu dogmă.** Pentru a proteja pur și simplu starea shared, un mutex este mai clar și mai eficient decât să conturezi logica în channels.

## De ce contează

Știind când să utilizezi pachetul `sync` versus channels este un semn cheie al maturității concurenței în Go.

Deși Go promovează channels ("share memory by communicating"), aceasta este o ghidă — și o greșeală comună este forțarea channels acolo unde un simplu **mutex** ar fi mai clar și mai rapid.

Pachetul `sync` este instrumentul corect și idiomativ pentru **protejarea stării shared** (contoare, cachele, maps): mutexuri pentru acces exclusiv, `RWMutex` pentru date read-heavy, `WaitGroup` pentru așteptarea goroutinelor, `Once` pentru inițializare unică, și `atomic`/`sync.Map` pentru cazuri specializate.

Înțelegând că channels excelează la *comunicare și coordonare* în timp ce primitivele sync excelează la *protejarea memoriei shared* — și alegând instrumentul adecvat mai degrabă decât dogmatic folosind channels — duce la cod concurrent mai simplu, mai eficient și mai corect.

Această judecată este exact ceea ce deosebește dezvoltatorii Go experimentați și este un subiect frecvent în interviurile avansate.