# Nebenläufigkeit in Go: Goroutinen und Kanäle - Vollständiger Leitfaden > Beherrschen Sie die Nebenläufigkeit in Go mit Goroutinen und Kanälen. Fortgeschrittene Muster, Synchronisation, select-Anweisungen und Best Practices mit detaillierten Codebeispielen. - Published: 2026-02-21 - Updated: 2026-04-29 - Author: SharpSkill - Tags: go, golang, concurrency, goroutines, channels - Reading time: 14 min --- Die Nebenläufigkeit gehört zu den größten Stärken von Go. Im Gegensatz zu anderen Sprachen, in denen Multithreading komplex bleibt, bietet Go ein elegantes Modell auf Basis von Goroutinen und Kanälen, das die Entwicklung nebenläufiger Anwendungen erheblich vereinfacht. > **Go-Philosophie** > > "Kommuniziere nicht, indem du Speicher teilst; teile Speicher, indem du kommunizierst." Dieses grundlegende Prinzip leitet das gesamte Nebenläufigkeitsdesign in Go. ## Goroutinen verstehen Goroutinen sind leichtgewichtige Threads, die vom Go-Runtime verwaltet werden. Sie verbrauchen rund 2 KB Stack-Speicher (gegenüber mehreren MB für Betriebssystem-Threads) und ermöglichen Tausende von nebenläufigen Aufgaben ohne Systemüberlastung. Das Starten einer Goroutine erfordert lediglich das Voranstellen des Schlüsselworts `go` vor einen Funktionsaufruf. Das Runtime kümmert sich um Scheduling und Verteilung auf die verfügbaren Threads. ```go // goroutines_basic.go package main import ( "fmt" "time" ) // fetchData simulates a network request func fetchData(id int) { // Simulates network delay time.Sleep(100 * time.Millisecond) fmt.Printf("Data %d fetched\n", id) } func main() { // Sequential execution - 500ms total start := time.Now() for i := 1; i <= 5; i++ { fetchData(i) } fmt.Printf("Sequential: %v\n", time.Since(start)) // Concurrent execution - ~100ms total start = time.Now() for i := 1; i <= 5; i++ { go fetchData(i) // Execute as goroutine } time.Sleep(150 * time.Millisecond) // Wait for completion fmt.Printf("Concurrent: %v\n", time.Since(start)) } ``` Die nebenläufige Ausführung reduziert die Gesamtzeit von 500 ms auf etwa 100 ms. Allerdings ist die Verwendung von `time.Sleep` zur Synchronisation von Goroutinen keine bewährte Praxis. Kanäle bieten eine elegante Lösung. ## Kanäle: Kommunikation zwischen Goroutinen Ein Kanal ist eine typisierte Leitung zum Senden und Empfangen von Werten zwischen Goroutinen. Kanäle gewährleisten die Synchronisation: Eine sendende Goroutine wartet, bis eine andere empfängt, und umgekehrt. Die Erstellung eines Kanals erfolgt mit der Funktion `make`. Der Operator `<-` sendet und empfängt Daten, abhängig von seiner Position relativ zum Kanal. ```go // channels_basic.go package main import "fmt" // worker performs computation and returns result via channel func worker(id int, jobs <-chan int, results chan<- int) { // Receives jobs until channel closes for job := range jobs { result := job * 2 // Processing results <- result // Send result } } func main() { // Create channels jobs := make(chan int, 10) // Buffered channel results := make(chan int, 10) // Start 3 workers for w := 1; w <= 3; w++ { go worker(w, jobs, results) } // Send 5 jobs for j := 1; j <= 5; j++ { jobs <- j } close(jobs) // Signal end of jobs // Collect results for r := 1; r <= 5; r++ { result := <-results fmt.Printf("Result: %d\n", result) } } ``` Gerichtete Kanäle (`<-chan` für Empfang, `chan<-` für Senden) erhöhen die Code-Sicherheit, indem sie die möglichen Operationen einschränken. ## Gepufferte vs. ungepufferte Kanäle Die Unterscheidung zwischen diesen Kanaltypen wirkt sich direkt auf das Synchronisationsverhalten zwischen Goroutinen aus. Ungepufferte Kanäle blockieren den Sender, bis ein Empfänger bereit ist. Gepufferte Kanäle ermöglichen das Senden von bis zu N Werten ohne Blockierung, wobei N die Pufferkapazität darstellt. ```go // buffered_channels.go package main import "fmt" func main() { // Unbuffered channel - strict synchronization unbuffered := make(chan string) go func() { unbuffered <- "message" // Blocks until received }() msg := <-unbuffered // Unblocks the send fmt.Println(msg) // Buffered channel - capacity of 2 buffered := make(chan int, 2) // These sends don't block buffered <- 1 buffered <- 2 // buffered <- 3 // Would block because buffer is full fmt.Println(<-buffered) // 1 fmt.Println(<-buffered) // 2 // Check capacity fmt.Printf("Length: %d, Capacity: %d\n", len(buffered), cap(buffered)) } ``` Gepufferte Kanäle entkoppeln Produzenten und Konsumenten, während ungepufferte eine Punkt-zu-Punkt-Synchronisation gewährleisten. > **Vorsicht vor Deadlocks** > > Ein Deadlock tritt auf, wenn alle Goroutinen wartend blockiert sind. Das Go-Runtime erkennt dies und beendet das Programm mit einer expliziten Fehlermeldung. ## Select: Multiplexing von Kanälen Die Anweisung `select` wartet auf gleichzeitige Operationen auf mehreren Kanälen. Sie ähnelt einer switch-Anweisung für nebenläufige Kommunikation. Diese Konstruktion ist unverzichtbar für die Verwaltung von Timeouts, Abbrüchen und mehreren Kommunikationen, ohne sich unbegrenzt auf einen einzelnen Kanal zu blockieren. ```go // select_example.go package main import ( "fmt" "time" ) // fetchAPI simulates an API call with variable delay func fetchAPI(name string, delay time.Duration, ch chan<- string) { time.Sleep(delay) ch <- fmt.Sprintf("%s: data received", name) } func main() { api1 := make(chan string) api2 := make(chan string) // Launch two API calls in parallel go fetchAPI("API-1", 100*time.Millisecond, api1) go fetchAPI("API-2", 200*time.Millisecond, api2) // Global timeout of 150ms timeout := time.After(150 * time.Millisecond) // Collect results with timeout for i := 0; i < 2; i++ { select { case result := <-api1: fmt.Println(result) case result := <-api2: fmt.Println(result) case <-timeout: fmt.Println("Timeout - operation cancelled") return } } } ``` Das `select` wählt den ersten verfügbaren Kanal aus. Sind mehrere bereit, ist die Auswahl pseudozufällig, um Verhungern zu vermeiden. ## Worker-Pool-Muster Das Worker-Pool-Muster verteilt Aufgaben auf mehrere Worker, begrenzt die Nebenläufigkeit und optimiert die Ressourcennutzung. Dieses Muster ist unverzichtbar für die Verarbeitung großer Datenmengen. Die Implementierung basiert auf einem zwischen den Workern geteilten Aufgabenkanal und einem Ergebniskanal für die Sammlung. ```go // worker_pool.go package main import ( "fmt" "sync" "time" ) // Task represents a unit of work type Task struct { ID int Data string } // Result contains the processing result type Result struct { TaskID int Output string } // worker processes received tasks func worker(id int, tasks <-chan Task, results chan<- Result, wg *sync.WaitGroup) { defer wg.Done() for task := range tasks { // Simulate processing time.Sleep(50 * time.Millisecond) results <- Result{ TaskID: task.ID, Output: fmt.Sprintf("Worker %d processed: %s", id, task.Data), } } } func main() { const numWorkers = 3 const numTasks = 10 tasks := make(chan Task, numTasks) results := make(chan Result, numTasks) var wg sync.WaitGroup // Start workers for w := 1; w <= numWorkers; w++ { wg.Add(1) go worker(w, tasks, results, &wg) } // Send tasks for i := 1; i <= numTasks; i++ { tasks <- Task{ID: i, Data: fmt.Sprintf("task-%d", i)} } close(tasks) // Close results channel after workers finish go func() { wg.Wait() close(results) }() // Collect results for result := range results { fmt.Printf("Task %d: %s\n", result.TaskID, result.Output) } } ``` Die `sync.WaitGroup` koordiniert das Warten auf alle Worker, bevor der Ergebniskanal geschlossen wird. ## Fan-Out/Fan-In-Muster Dieses Muster verteilt die Arbeit auf mehrere Goroutinen (Fan-Out) und aggregiert dann die Ergebnisse (Fan-In). Es maximiert die Parallelität und vereinfacht gleichzeitig die Sammlung der Ergebnisse. ```go // fan_out_fan_in.go package main import ( "fmt" "sync" ) // generate produces numbers on a channel func generate(nums ...int) <-chan int { out := make(chan int) go func() { for _, n := range nums { out <- n } close(out) }() return out } // square computes the square of received numbers func square(in <-chan int) <-chan int { out := make(chan int) go func() { for n := range in { out <- n * n } close(out) }() return out } // merge combines multiple channels into one (fan-in) func merge(channels ...<-chan int) <-chan int { out := make(chan int) var wg sync.WaitGroup // Output function for each channel output := func(c <-chan int) { defer wg.Done() for n := range c { out <- n } } // Launch a goroutine per channel wg.Add(len(channels)) for _, c := range channels { go output(c) } // Close after all goroutines finish go func() { wg.Wait() close(out) }() return out } func main() { // Generate data numbers := generate(1, 2, 3, 4, 5, 6, 7, 8) // Fan-out: distribute to 3 workers sq1 := square(numbers) sq2 := square(numbers) sq3 := square(numbers) // Fan-in: aggregate results for result := range merge(sq1, sq2, sq3) { fmt.Println(result) } } ``` Dieses Muster eignet sich hervorragend für verteilbare CPU-gebundene Operationen und Datenverarbeitungs-Pipelines. ## Context für Abbruch und Deadlines Das Paket `context` standardisiert die Verwaltung von Abbrüchen, Deadlines und Werten zwischen Goroutinen. Jede länger laufende Goroutine sollte einen Context als ersten Parameter akzeptieren. ```go // context_example.go package main import ( "context" "fmt" "time" ) // fetchWithContext simulates a cancellable request func fetchWithContext(ctx context.Context, url string) (string, error) { // Simulates a long operation select { case <-time.After(2 * time.Second): return fmt.Sprintf("Data from %s", url), nil case <-ctx.Done(): return "", ctx.Err() // context.Canceled or context.DeadlineExceeded } } func main() { // Context with 500ms timeout ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond) defer cancel() // Release resources result, err := fetchWithContext(ctx, "https://api.example.com") if err != nil { fmt.Printf("Error: %v\n", err) return } fmt.Println(result) // Context with manual cancellation ctx2, cancel2 := context.WithCancel(context.Background()) go func() { time.Sleep(100 * time.Millisecond) cancel2() // Explicit cancellation }() result, err = fetchWithContext(ctx2, "https://api2.example.com") if err != nil { fmt.Printf("Request cancelled: %v\n", err) } } ``` > **Bewährte Praxis** > > Immer `defer cancel()` direkt nach dem Erstellen eines Contexts aufrufen, um Ressourcenlecks zu vermeiden. ## Synchronisation mit sync.Mutex Obwohl Kanäle für die Kommunikation bevorzugt werden, bleibt das Paket `sync` notwendig, um den nebenläufigen Zugriff auf gemeinsam genutzte Datenstrukturen zu schützen. ```go // mutex_example.go package main import ( "fmt" "sync" ) // SafeCounter is a thread-safe counter type SafeCounter struct { mu sync.Mutex value map[string]int } // Increment increments the value for a given key func (c *SafeCounter) Increment(key string) { c.mu.Lock() // Exclusive lock defer c.mu.Unlock() // Guaranteed unlock c.value[key]++ } // Value returns the current value func (c *SafeCounter) Value(key string) int { c.mu.Lock() defer c.mu.Unlock() return c.value[key] } func main() { counter := SafeCounter{value: make(map[string]int)} var wg sync.WaitGroup // 1000 concurrent increments for i := 0; i < 1000; i++ { wg.Add(1) go func() { defer wg.Done() counter.Increment("visits") }() } wg.Wait() fmt.Printf("Total: %d\n", counter.Value("visits")) // 1000 } ``` Die `sync.RWMutex` optimiert nebenläufige Lesevorgänge mit `RLock()`/`RUnlock()` für reine Leseoperationen. ## Häufige Fehler und Lösungen Die Nebenläufigkeit in Go birgt klassische Fallstricke. Hier sind die häufigsten Fehler und wie sie vermieden werden können. ```go // common_mistakes.go package main import ( "fmt" "sync" ) func main() { // ERROR: Loop variable capture // All goroutines would print the same value for i := 0; i < 3; i++ { go func() { fmt.Println(i) // Capture by reference - BUG }() } // SOLUTION: Pass value as parameter var wg sync.WaitGroup for i := 0; i < 3; i++ { wg.Add(1) go func(n int) { defer wg.Done() fmt.Println(n) // Local copy - CORRECT }(i) } wg.Wait() // ERROR: Send on nil channel var ch chan int // ch <- 1 // Blocks forever // SOLUTION: Always initialize with make ch = make(chan int, 1) ch <- 1 fmt.Println(<-ch) // ERROR: Send on closed channel done := make(chan bool) close(done) // done <- true // Panic! // SOLUTION: Check before send or use sync.Once select { case done <- true: fmt.Println("Sent") default: fmt.Println("Channel closed or full") } } ``` Die Erkennung von Race Conditions verwendet das Flag `-race` während der Kompilierung oder beim Testen: `go test -race ./...`. ## Fazit Die Beherrschung der Nebenläufigkeit in Go beruht auf einigen Schlüsselkonzepten, die, einmal verstanden, den Aufbau hochleistungsfähiger Anwendungen ermöglichen. **Kernpunkte:** ✅ Goroutinen sind leicht und günstig - das Erstellen Tausender bleibt vertretbar ✅ Kanäle synchronisieren und übertragen Daten zwischen Goroutinen ✅ Die Anweisung `select` verwaltet mehrere Kommunikationen und Timeouts ✅ Das Worker-Pool-Muster begrenzt die Nebenläufigkeit und optimiert Ressourcen ✅ Das Paket `context` standardisiert Abbruch und Deadlines ✅ Mutexe schützen gemeinsame Daten, wenn Kanäle nicht ausreichen ✅ Das Flag `-race` erkennt Race Conditions während der Tests Die Philosophie "Speicher durch Kommunikation teilen" führt zu sichereren und wartungsfreundlicheren Designs als das traditionelle Multithreading mit Locks. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/de/blog/go/go-concurrency-goroutines-channels