Mikor használod a sync csomagot csatornák helyett?

Question

Accepted Answer

A Go két megközelítést kínál az egyidejűség biztonsága érdekében: **csatornákat** ("memória megosztása kommunikációval") és a **`sync` csomag** (mutex/zárakat az megosztott memória közvetlen védelméhez). A Go csatorna-első filozófiája ellenére a sync primitívek gyakran az egyszerűbb, hatékonyabb választás a megosztott állapot védelméhez.

## sync.Mutex — megosztott állapot védelme zárral

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

A `Mutex` biztosítja, hogy egyszerre csak egy goroutine férjen hozzá a védett adatokhoz, megakadályozva az adatversenyt. A `Lock()`/`defer Unlock()` minta idiomatikus.

## sync.RWMutex — sok olvasó VAGY egy írót

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

A `RWMutex` egyidejű olvasást tesz lehetővé, de kizárólagos írást — ideális olvasás-intenzív adatokhoz, például gyorsítótárakhoz.

## Egyéb sync primitívek

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

## Mikor használj sync-et vs csatornákat

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

A gyakorlati szabály: **"Ne kommunikálj memória megosztásával" egy irányelvés, nem dogma.** Az egyszerű megosztott állapot védelméhez a mutex világosabb és hatékonyabb, mint a logika csatornákba való erőltetése.

## Miért fontos

Annak tudása, hogy mikor használd a `sync` csomagot a csatornákkal szemben, a Go egyidejűség érésének kulcsa.

Bár a Go a csatornákat támogatja ("memória megosztása kommunikációval"), ez egy irányelvés — és egy gyakori hiba az, hogy csatornákat erőltetsz oda, ahol egy egyszerű **mutex** világosabb és gyorsabb lenne.

A `sync` csomag a megfelelő, idiomatikus eszköz a **megosztott állapot védelméhez** (számlálók, gyorsítótárak, térképek): mutex az exkluzív hozzáféréshez, `RWMutex` az olvasás-intenzív adatokhoz, `WaitGroup` a goroutine-okra való várakozáshoz, `Once` az egyszeri inicializáláshoz, és `atomic`/`sync.Map` a speciális esetekhez.

Annak megértése, hogy a csatornák a *kommunikációban és koordinációban* tűnnek ki, míg a sync primitívek a *megosztott memória őrzésében* — és a megfelelő eszköz választása az eszközt dogmatikusan használó helyett — egyszerűbb, hatékonyabb és helyes egyidejű kódhoz vezet.

Ez a megítélés pontosan az, ami megkülönbözteti a tapasztalt Go fejlesztőket, és gyakori haladó szintű interjúkérdés.