Golang Mutex: sync.Mutex, RWMutex, atomic und sync.Once

Geteilte Daten schützen

Ein sync.Mutex lässt immer nur eine Goroutine in den Code zwischen Lock und Unlock. Setz den Mutex neben die Daten, die er schützt, meist in dasselbe Struct:

package main

import (
	"fmt"
	"sync"
)

type Counter struct {
	mu     sync.Mutex
	counts map[string]int
}

func (c *Counter) Inc(key string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.counts[key]++
}

func (c *Counter) Get(key string) int {
	c.mu.Lock()
	defer c.mu.Unlock()
	return c.counts[key]
}

func main() {
	c := Counter{counts: make(map[string]int)}

	var wg sync.WaitGroup
	for range 100 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for range 100 {
				c.Inc("hits")
			}
		}()
	}
	wg.Wait()

	fmt.Println("hits:", c.Get("hits"))
}

Das gibt immer hits: 10000 aus. Ohne das Lock würden 100 Goroutinen, die dieselbe Map schreiben, das Programm meist mit fatal error: concurrent map writes abstürzen lassen. Dieser Fehler kommt von einer Prüfung der Runtime, die nach bestem Bemühen arbeitet, er lässt sich nicht abfangen, und das Ausbleiben eines Absturzes beweist nicht, dass der Code korrekt ist.

Details, die zählen:

• Der Nullwert von sync.Mutex ist entsperrt und einsatzbereit. Kein Konstruktor nötig.
• Methoden verwenden einen Pointer Receiver (*Counter). Ein Value Receiver würde eine Kopie des Mutex sperren, und die schützt nichts.
• defer c.mu.Unlock() direkt nach Lock sorgt dafür, dass jeder Return-Pfad und auch eine Panic das Lock freigibt.
• Jeder Zugriff läuft über das Lock, auch Lesezugriffe. Ein Lesen ohne Lock, während eine andere Goroutine schreibt, bleibt ein Data Race.

Den kritischen Abschnitt klein halten

defer entsperrt am Ende der Funktion. Für kurze Methoden wie die oben ist das richtig. In einer längeren Funktion entsperrst du, sobald die geteilten Daten nicht mehr angefasst werden, damit andere Goroutinen nicht auf Arbeit warten, die das Lock gar nicht braucht:

func (s *Store) Save(key string) error {
	s.mu.Lock()
	data := s.items[key] // copy what you need
	s.mu.Unlock()

	return writeToDisk(key, data) // slow I/O, outside the lock
}

Ein Lock über Netzwerkaufrufe, Festplatten-I/O oder das Senden auf einen Channel hinweg zu halten ist die häufigste Ursache für ein langsames nebenläufiges Programm, und ein Channel-Send unter einem Lock ist eine häufige Ursache für Deadlocks.

RWMutex für leseintensive Daten

sync.RWMutex hat zwei Modi. RLock/RUnlock nehmen ein geteiltes Lese-Lock, das viele Goroutinen gleichzeitig halten können. Lock/Unlock nehmen das exklusive Schreib-Lock, das wartet, bis alle Leser weg sind.

package main

import (
	"fmt"
	"sync"
)

type Config struct {
	mu     sync.RWMutex
	values map[string]string
}

func (c *Config) Get(key string) (string, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	v, ok := c.values[key]
	return v, ok
}

func (c *Config) Set(key, value string) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.values[key] = value
}

func main() {
	cfg := &Config{values: map[string]string{"mode": "dev"}}

	var wg sync.WaitGroup
	for range 50 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			cfg.Get("mode") // many readers at the same time
		}()
	}
	wg.Add(1)
	go func() {
		defer wg.Done()
		cfg.Set("mode", "prod") // one writer, exclusive
	}()
	wg.Wait()

	v, _ := cfg.Get("mode")
	fmt.Println("mode:", v)
}

RWMutex lohnt sich, wenn Lesezugriffe dominieren und jeder davon unter dem Lock echte Arbeit leistet. Bei winzigen kritischen Abschnitten wie einem einzelnen Map-Lookup ist ein einfacher Mutex oft genauso schnell, weil das Lese-Lock eigene Verwaltung mitbringt. Mach vor der Entscheidung einen Benchmark.

Ein Lese-Lock lässt sich nicht zu einem Schreib-Lock hochstufen. Lock aufzurufen, während dieselbe Goroutine RLock hält, führt zum Deadlock. Gib zuerst das Lese-Lock frei, nimm dann das Schreib-Lock und prüf die Bedingung erneut, da ein anderer Schreiber die Daten inzwischen geändert haben kann.

sync/atomic für einzelne Werte

Für einen einzelnen Zähler oder ein Flag ist sync/atomic einfacher und billiger als ein Mutex. Die typisierten Wrapper (Go 1.19) sind die richtige Wahl:

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

func main() {
	var requests atomic.Int64
	var ready atomic.Bool

	var wg sync.WaitGroup
	for range 1000 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			requests.Add(1)
		}()
	}
	wg.Wait()
	ready.Store(true)

	fmt.Println("requests:", requests.Load())
	fmt.Println("ready:", ready.Load())

	// CompareAndSwap: set only if the current value is what you expect.
	fmt.Println("swapped:", requests.CompareAndSwap(1000, 0), "now:", requests.Load())
}

Atomics schützen jeweils einen Wert. Sobald sich zwei Werte gemeinsam ändern müssen (ein Kontostand und eine Anzahl Transaktionen, eine Map und ihre Größe), nimm einen Mutex. Zwischen zwei separaten atomaren Operationen können sich andere Goroutinen einschieben.

sync.Once

sync.Once führt eine Funktion genau einmal aus, egal wie viele Goroutinen sie gleichzeitig aufrufen. Jeder, der Do aufruft, wartet, bis der erste Aufruf fertig ist. Das ist der Standardweg für eine verzögerte Initialisierung:

package main

import (
	"fmt"
	"sync"
)

var (
	once   sync.Once
	config map[string]string
)

func loadConfig() map[string]string {
	once.Do(func() {
		fmt.Println("loading config (runs once)")
		config = map[string]string{"env": "prod"}
	})
	return config
}

// Go 1.21: OnceValue wraps a function and caches its result.
var port = sync.OnceValue(func() int {
	fmt.Println("computing port (runs once)")
	return 8080
})

func main() {
	var wg sync.WaitGroup
	for range 5 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			_ = loadConfig()
			_ = port()
		}()
	}
	wg.Wait()
	fmt.Println(loadConfig()["env"], port())
}

Jede „runs once“-Zeile erscheint genau einmal. Löst die an Do übergebene Funktion eine Panic aus, zählt Once sie trotzdem als erledigt und versucht es nie erneut. sync.OnceValues macht dasselbe für Funktionen, die zwei Werte zurückgeben, typischerweise einen Wert und einen Fehler.

Mutex, Channel oder sync.Map

sync.Map ist kein allgemeiner Ersatz für eine Map mit Lock. Es hat keine Typparameter, Werte kommen also als any zurück, und es ist nur in den beiden Fällen aus der Tabelle schneller. Fang mit einem Mutex und einer normalen Map an.

Häufige Fehler

• Einen Mutex kopieren. Ein Struct mit einem sync.Mutex als Wert zu übergeben oder einen Value Receiver zu verwenden kopiert das Lock. go vet meldet passes lock by value oder copies lock value.
• Zweimal in einer Goroutine sperren. Go-Mutexe sind nicht reentrant. Ruft Inc Get auf und nehmen beide das Lock, blockiert Inc für immer. Lass öffentliche Methoden sperren und private Helfer davon ausgehen, dass das Lock gehalten wird.
• Das Entsperren bei einem frühen Return vergessen. Nimm defer, außer du hast einen Grund dagegen.
• In unterschiedlicher Reihenfolge sperren. Nimmt eine Goroutine Lock A und dann B, während eine andere B und dann A nimmt, können beide ewig aufeinander warten. Nimm mehrere Locks immer in derselben Reihenfolge.
• Die geschützten Daten herausgeben. Gibt eine Methode die interne Map zurück, können Aufrufer sie ohne Lock lesen und schreiben. Gib eine Kopie zurück (maps.Clone, Go 1.21) oder einen einzelnen Wert.
• Nur die Schreibzugriffe schützen. Lesezugriffe ohne Lock parallel zu Schreibzugriffen mit Lock sind trotzdem Races. Führ deine Tests mit go test -race aus.