Wann verwendest du das sync-Paket statt channels?

Question

Accepted Answer

Go bietet zwei Ansätze für Concurrency-Sicherheit: **channels** ("teile Speicher durch Kommunikation") und das **`sync`-Paket** (Mutexes/Sperren zum direkten Schutz gemeinsamer Speicher). Trotz Gos Channel-First-Philosophie sind sync-Primitive oft die einfacherer und effizientere Wahl zum Schutz gemeinsamen Zustands.

## sync.Mutex — gemeinsamen Zustand mit einer Sperre schützen

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

Ein `Mutex` stellt sicher, dass jeweils nur eine Goroutine auf die geschützten Daten zugreift, um Race Conditions zu vermeiden. Das Muster `Lock()`/`defer Unlock()` ist idiomatisch.

## sync.RWMutex — viele Leser ODER ein Schreiber

```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` ermöglicht gleichzeitiges Lesen, aber exklusives Schreiben — ideal für leseintensive Daten wie Caches.

## Weitere sync-Primitive

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

## Wann sync versus channels verwenden

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

Die praktische Regel: **"Kommuniziere nicht durch Speicherteilung" ist eine Richtlinie, keine Dogma.** Um einfach gemeinsamen Zustand zu schützen, ist ein Mutex klarer und effizienter als die Logik in channels zu verzerren.

## Warum es wichtig ist

Zu wissen, wann man das `sync`-Paket statt channels verwendet, ist ein Schlüsselzeichen von Go-Concurrency-Reife.

Obwohl Go channels bewirbt ("teile Speicher durch Kommunikation"), ist dies eine Richtlinie — und ein häufiger Fehler ist, channels zu erzwingen, wo ein einfacher **Mutex** klarer und schneller wäre.

Das `sync`-Paket ist das richtige, idiomatische Werkzeug zum **Schutz gemeinsamen Zustands** (Zähler, Caches, Maps): Mutexes für exklusiven Zugriff, `RWMutex` für leseintensive Daten, `WaitGroup` zum Warten auf Goroutines, `Once` für einmalige Initialisierung und `atomic`/`sync.Map` für spezielle Fälle.

Zu verstehen, dass channels bei *Kommunikation und Koordination* hervorragend sind, während sync-Primitive bei *Schutz gemeinsamer Speicher* hervorragend sind — und das passende Werkzeug zu wählen, anstatt dogmatisch channels zu verwenden — führt zu einfacherem, effizienteren und korrekteren nebenläufigen Code.

Diese Urteilsfähigkeit ist genau das, was erfahrene Go-Entwickler auszeichnet, und es ist ein häufig fortgeschrittenes Interviewthema.