Forem: Amin Mohammadi

Goroutines vs. OS-Threads in Go: Einfacher Leitfaden für Anfänger

Amin Mohammadi — Mon, 01 Dec 2025 16:13:39 +0000

Wenn du gerade mit Go anfängst, hörst du oft von Goroutines – aber was sind sie eigentlich? Und warum sind sie anders als normale OS Threads (Betriebssystem-Threads)?

In diesem Artikel erklären wir dir:

Was OS Threads sind (ganz einfach)
Was Goroutines sind
Warum Goroutines in Go so beliebt sind
Praktische Beispiele zum Ausprobieren

Alles auf einem Anfänger-Level, damit du direkt loslegen kannst!

1. Was sind OS Threads? (Die "Klassischen" Threads)

Ein OS Thread (Operating System Thread) ist eine Einheit, die vom Betriebssystem verwaltet wird. Jeder Thread hat:

Seinen eigenen Stack (Speicherbereich für lokale Variablen)
Seinen eigenen Programmzähler (wo im Code er gerade ist)
Wird vom Betriebssystem geplant (Scheduler)

Ein Einfaches Beispiel mit OS Threads in Go

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
)

func main() {
    // Wie viele OS Threads Go verwenden kann
    fmt.Printf("Anzahl OS Threads: %d\n", runtime.GOMAXPROCS(0))

    var wg sync.WaitGroup

    // Wir starten 5 OS Threads
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Printf("Thread %d läuft\n", id)
            time.Sleep(1 * time.Second)
        }(i)
    }

    wg.Wait()
    fmt.Println("Alle Threads fertig!")
}

Was passiert hier?

runtime.GOMAXPROCS(0) zeigt dir, wie viele echte OS Threads Go verwenden kann
Standardmäßig ist das die Anzahl deiner CPU-Kerne
Jede go-Funktion läuft auf einem OS Thread

Problem: OS Threads sind schwer (heavyweight):

Jeder Thread braucht viel Speicher (meist 1-2 MB pro Thread)
Das Betriebssystem muss sie planen (Scheduling) – das kostet Zeit
Du kannst nicht Tausende von OS Threads gleichzeitig haben

2. Was sind Goroutines? (Die "Leichten" Threads von Go)

Eine Goroutine ist eine leichte Funktion, die parallel laufen kann. Sie wird nicht vom Betriebssystem, sondern von Go selbst verwaltet.

Ein Einfaches Beispiel mit Goroutines

package main

import (
    "fmt"
    "sync"
    "time"
)

func main() {
    var wg sync.WaitGroup

    // Wir starten 1000 Goroutines – das wäre mit OS Threads unmöglich!
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Printf("Goroutine %d läuft\n", id)
            time.Sleep(100 * time.Millisecond)
        }(i)
    }

    wg.Wait()
    fmt.Println("Alle Goroutines fertig!")
}

Was ist der Unterschied?

Goroutines sind super leicht: Nur 2-8 KB Speicher pro Goroutine
Go verwaltet sie selbst: Der Go-Scheduler teilt OS Threads zwischen Goroutines auf
Du kannst Millionen starten: Praktisch keine Grenze!

3. Der Wichtigste Unterschied: Speicherverbrauch

Lass uns das praktisch testen:

3.1. Test: Wie Viele OS Threads Können Wir Starten?

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
)

func main() {
    var wg sync.WaitGroup
    var mu sync.Mutex
    var count int

    // Versuchen wir, 10.000 "Threads" zu starten
    // (In Go sind das eigentlich Goroutines, die auf OS Threads laufen)
    for i := 0; i < 10000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            time.Sleep(1 * time.Second)
            mu.Lock()
            count++
            mu.Unlock()
        }()
    }

    wg.Wait()
    fmt.Printf("Anzahl fertiger Goroutines: %d\n", count)
    fmt.Printf("Anzahl OS Threads verwendet: %d\n", runtime.GOMAXPROCS(0))
}

Ergebnis:

Du kannst 10.000 Goroutines starten
Aber Go verwendet nur 4-8 OS Threads (je nach CPU)
Der Go-Scheduler teilt die Goroutines auf diese Threads auf

4. Wie Funktioniert der Go-Scheduler?

Der Go-Scheduler ist wie ein Manager, der entscheidet, welche Goroutine wann läuft:

OS Thread 1: [Goroutine A] → [Goroutine B] → [Goroutine C] → ...
OS Thread 2: [Goroutine D] → [Goroutine E] → [Goroutine F] → ...
OS Thread 3: [Goroutine G] → [Goroutine H] → [Goroutine I] → ...

Wie funktioniert das?

Eine Goroutine läuft auf einem OS Thread
Wenn sie blockiert (z.B. auf I/O wartet), gibt sie den Thread frei
Eine andere Goroutine kann dann auf diesem Thread laufen
So teilen sich Tausende Goroutines nur wenige OS Threads

Beispiel: Blockierende Operationen

package main

import (
    "fmt"
    "net/http"
    "sync"
    "time"
)

func fetchURL(url string, wg *sync.WaitGroup) {
    defer wg.Done()

    // Diese Operation blockiert (wartet auf Netzwerk)
    resp, err := http.Get(url)
    if err != nil {
        fmt.Printf("Fehler bei %s: %v\n", url, err)
        return
    }
    defer resp.Body.Close()

    fmt.Printf("URL %s geladen: Status %d\n", url, resp.StatusCode)
}

func main() {
    var wg sync.WaitGroup
    urls := []string{
        "https://www.google.com",
        "https://www.github.com",
        "https://www.stackoverflow.com",
    }

    // Alle URLs werden parallel geladen
    for _, url := range urls {
        wg.Add(1)
        go fetchURL(url, &wg)
    }

    wg.Wait()
    fmt.Println("Alle URLs geladen!")
}

Was passiert hier?

Jede fetchURL-Goroutine blockiert, während sie auf die HTTP-Antwort wartet
Während sie wartet, kann eine andere Goroutine auf demselben OS Thread laufen
So können wir viele Netzwerk-Anfragen parallel machen, ohne viele OS Threads zu brauchen

5. Praktischer Vergleich: Performance

Lass uns ein praktisches Beispiel machen, das den Unterschied zeigt:

5.1. Beispiel: Viele Zahlen Addieren

package main

import (
    "fmt"
    "sync"
    "time"
)

// Funktion, die etwas "Arbeit" macht
func calculateSum(start, end int, result *int, wg *sync.WaitGroup) {
    defer wg.Done()
    sum := 0
    for i := start; i < end; i++ {
        sum += i
        // Simuliere etwas Arbeit
        time.Sleep(1 * time.Millisecond)
    }
    *result = sum
}

func main() {
    start := time.Now()
    var wg sync.WaitGroup
    results := make([]int, 100)

    // Starte 100 Goroutines
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go calculateSum(i*100, (i+1)*100, &results[i], &wg)
    }

    wg.Wait()
    elapsed := time.Since(start)

    total := 0
    for _, r := range results {
        total += r
    }

    fmt.Printf("Gesamtsumme: %d\n", total)
    fmt.Printf("Zeit: %v\n", elapsed)
}

Warum ist das schnell?

100 Goroutines laufen parallel
Sie teilen sich nur 4-8 OS Threads
Der Go-Scheduler wechselt schnell zwischen ihnen
Viel schneller als wenn wir alles nacheinander machen würden!

6. Wann Verwende Ich Was?

OS Threads (Direkt in Go selten nötig)

Du musst selten direkt mit OS Threads arbeiten in Go, weil:

Goroutines sind einfacher zu verwenden
Sie sind effizienter
Go verwaltet sie automatisch

Aber: Manchmal brauchst du OS Threads für:

C-Bibliotheken, die Threads erwarten
Sehr spezielle System-Programmierung

Goroutines (Das Standard-Tool in Go)

Verwende Goroutines für:

✅ Parallele Netzwerk-Anfragen (HTTP, Datenbanken)
✅ Parallele Berechnungen
✅ Concurrent Programming (mehrere Dinge gleichzeitig)
✅ Worker Pools (viele Aufgaben parallel abarbeiten)

7. Ein Praktisches Beispiel: Worker Pool

Ein Worker Pool ist ein Muster, bei dem du eine begrenzte Anzahl von Goroutines hast, die viele Aufgaben abarbeiten:

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
    defer wg.Done()
    for job := range jobs {
        fmt.Printf("Worker %d bearbeitet Job %d\n", id, job)
        // Simuliere Arbeit
        time.Sleep(500 * time.Millisecond)
        results <- job * 2 // Ergebnis zurückgeben
    }
}

func main() {
    const numWorkers = 3  // Nur 3 Worker (Goroutines)
    const numJobs = 10    // 10 Jobs zu erledigen

    jobs := make(chan int, numJobs)
    results := make(chan int, numJobs)
    var wg sync.WaitGroup

    // Starte Worker (Goroutines)
    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go worker(w, jobs, results, &wg)
    }

    // Sende Jobs
    for j := 1; j <= numJobs; j++ {
        jobs <- j
    }
    close(jobs)

    // Warte auf Ergebnisse
    go func() {
        wg.Wait()
        close(results)
    }()

    // Zeige Ergebnisse
    for result := range results {
        fmt.Printf("Ergebnis: %d\n", result)
    }
}

Was passiert hier?

Wir haben nur 3 Worker-Goroutines
Sie bearbeiten 10 Jobs nacheinander
Jede Goroutine läuft auf einem OS Thread (geteilt)
Viel effizienter als 10 separate OS Threads!

8. Häufige Fehler und Tipps

Fehler 1: Goroutines ohne Synchronisation

// ❌ FALSCH
func main() {
    for i := 0; i < 10; i++ {
        go func() {
            fmt.Println(i) // Problem: i kann sich ändern!
        }()
    }
    time.Sleep(1 * time.Second) // Nicht zuverlässig!
}

// ✅ RICHTIG
func main() {
    var wg sync.WaitGroup
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            fmt.Println(id) // id ist eine Kopie
        }(i)
    }
    wg.Wait() // Warte auf alle Goroutines
}

Fehler 2: Zu Viele Goroutines

// ❌ FALSCH: Millionen Goroutines starten
for i := 0; i < 10000000; i++ {
    go doSomething()
}

// ✅ RICHTIG: Worker Pool verwenden
const maxWorkers = 100
jobs := make(chan int, 1000)

for w := 0; w < maxWorkers; w++ {
    go worker(jobs)
}

9. Zusammenfassung: Die Wichtigsten Unterschiede

Feature	OS Thread	Goroutine
Speicher	1-2 MB	2-8 KB
Verwaltung	Betriebssystem	Go Runtime
Anzahl	Hunderte	Millionen möglich
Scheduling	OS Scheduler	Go Scheduler
Geschwindigkeit	Langsamer (mehr Overhead)	Schneller (weniger Overhead)

Einfach gesagt:

OS Threads = Schwere Lastwagen (viel Kraft, aber teuer)
Goroutines = Leichte Motorräder (schnell, effizient, viele gleichzeitig)

10. Nächste Schritte

Jetzt, wo du den Unterschied verstehst, kannst du:

Mehr über Channels lernen (Kommunikation zwischen Goroutines)
Select-Statements ausprobieren (mehrere Channels gleichzeitig)
Context-Package verwenden (Goroutines abbrechen)
Sync-Package erkunden (Mutex, WaitGroup, etc.)

Praktische Übungen:

Baue einen einfachen Web-Scraper mit Goroutines
Erstelle einen Worker Pool für Datei-Verarbeitung
Implementiere parallele API-Aufrufe

Fazit

Goroutines sind die "Superkräfte" von Go
Sie sind viel leichter als OS Threads
Du kannst viele gleichzeitig verwenden
Der Go-Scheduler verwaltet sie automatisch
Perfekt für parallele Programmierung!

Denk daran: In Go verwendest du fast immer Goroutines, nicht direkt OS Threads. Go macht das für dich!

Weitere Ressourcen

Einfache Datenspeicherung in Go: Von In-Memory zu Redis

Amin Mohammadi — Mon, 01 Dec 2025 15:57:20 +0000

Einfache Daten-Speicherung in Go: Von In-Memory zu Redis

In vielen kleinen Go-Projekten fängt man damit an, Daten einfach im Speicher (In-Memory) zu halten. Das ist schnell und leicht zu verstehen – aber es hat klare Grenzen. In diesem Artikel schauen wir uns an:

Wie eine einfache In-Memory-Speicherung in Go aussieht
Welche Probleme dabei in der Praxis auftreten
Wie wir dieselbe Idee mit Redis robuster und skalierbar umsetzen

Beispiele sind bewusst einfach gehalten und richten sich an Einsteiger.

1. In-Memory-Speicher in Go – Der Einfache Start

Angenommen, wir wollen ein sehr kleines Key-Value-"Storage" bauen, z.B. um Tokens oder einfache Konfigurationen zu speichern.

1.1. Ein Einfacher Speicher mit `map`

package main

import (
    "fmt"
    "sync"
)

type InMemoryStore struct {
    mu   sync.RWMutex
    data map[string]string
}

func NewInMemoryStore() *InMemoryStore {
    return &InMemoryStore{
        data: make(map[string]string),
    }
}

func (s *InMemoryStore) Set(key, value string) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.data[key] = value
}

func (s *InMemoryStore) Get(key string) (string, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    val, ok := s.data[key]
    return val, ok
}

func main() {
    store := NewInMemoryStore()

    store.Set("username", "alice")
    if val, ok := store.Get("username"); ok {
        fmt.Println("Username:", val)
    }
}

Was passiert hier?

map[string]string hält unsere Daten im RAM
sync.RWMutex schützt die Map vor Race Conditions bei parallelen Zugriffen

Für ein einzelnes kleines Service funktioniert das zunächst sehr gut.

2. Wo In-Memory in Go zum Problem Wird

Sobald die Anwendung wächst, tauchen typische Probleme auf:

2.1. Daten Gehen beim Neustart Verloren

In-Memory-Daten leben nur so lange, wie der Prozess lebt
Neustart des Services = alle Daten sind weg

2.2. Skalierung mit Mehreren Instanzen

Wenn du mehrere Instanzen deiner Go-App hinter einem Load-Balancer betreibst, hat jede Instanz ihre eigene Map:

Instanz A speichert den Key username = alice
Instanz B kennt diesen Eintrag nicht
Je nach Load-Balancer-Routing bekommst du unterschiedliche Ergebnisse

2.3. Mehr Speicherverbrauch im Go-Prozess

Alle Daten liegen im Heap deiner Go-Applikation
Je mehr du speicherst, desto größer wird der Prozess und desto mehr Arbeit hat der Garbage Collector

Fazit: In-Memory in Go ist super für Cache, kurzfristige Daten oder Tests – aber nicht ideal für geteilten, dauerhaften Speicher.

3. Einführung in Redis als Externe In-Memory-Datenbank

Redis ist eine In-Memory-Datenbank, die speziell dafür gebaut wurde:

Daten im RAM zu halten (sehr schnell)
Von vielen Services gleichzeitig verwendet zu werden
Optional Daten auf Platte zu persistieren (Snapshots, AOF)

Anstatt unsere Daten in einer lokalen Go-map zu behalten, speichern wir sie im Redis-Server. Alle Instanzen deiner Anwendung reden mit demselben Redis.

4. Go + Redis: Ein Einfaches Beispiel

Wir verwenden das beliebte Go-Client-Package github.com/redis/go-redis/v9.

4.1. Abhängigkeit Hinzufügen

go get github.com/redis/go-redis/v9

4.2. Einen Einfachen Redis-Client in Go Bauen

package main

import (
    "context"
    "fmt"
    "log"
    "time"

    "github.com/redis/go-redis/v9"
)

var ctx = context.Background()

type RedisStore struct {
    client *redis.Client
}

func NewRedisStore(addr string) *RedisStore {
    rdb := redis.NewClient(&redis.Options{
        Addr:     addr,  // z.B. "localhost:6379"
        Password: "",    // kein Password per Default
        DB:       0,     // Default-DB
    })

    // Testverbindung
    if err := rdb.Ping(ctx).Err(); err != nil {
        log.Fatalf("Redis Verbindung fehlgeschlagen: %v", err)
    }

    return &RedisStore{client: rdb}
}

func (s *RedisStore) Set(key, value string, ttl time.Duration) error {
    // TTL = 0 bedeutet "ohne Ablaufdatum"
    return s.client.Set(ctx, key, value, ttl).Err()
}

func (s *RedisStore) Get(key string) (string, bool, error) {
    val, err := s.client.Get(ctx, key).Result()
    if err == redis.Nil {
        // Key existiert nicht
        return "", false, nil
    }
    if err != nil {
        return "", false, err
    }
    return val, true, nil
}

func main() {
    store := NewRedisStore("localhost:6379")

    // Beispiel: Key mit TTL von 1 Minute speichern
    if err := store.Set("username", "alice", time.Minute); err != nil {
        log.Fatalf("Set fehlgeschlagen: %v", err)
    }

    val, ok, err := store.Get("username")
    if err != nil {
        log.Fatalf("Get fehlgeschlagen: %v", err)
    }
    if ok {
        fmt.Println("Username:", val)
    } else {
        fmt.Println("Key nicht gefunden")
    }
}

Wichtige Punkte:

NewRedisStore baut den Client und prüft direkt mit PING, ob Redis erreichbar ist
Set unterstützt eine TTL (Time-to-Live)
Get unterscheidet zwischen "Key existiert nicht" (redis.Nil) und echten Fehlern

5. Vergleich: In-Memory vs. Redis

5.1. Architektur

In-Memory (Go-Map):

Daten liegen im gleichen Prozess wie deine App
Schnell, aber nur lokal verfügbar
Kein Sharing zwischen Instanzen

Redis:

Externer Service (Docker, VM, Kubernetes, ...)
Alle Instanzen deiner App greifen auf denselben Speicher zu
Besser geeignet für Skalierung und geteilten Zustand

5.2. Neustarts und Deployments

In-Memory:

Beim Restart sind alle Daten weg

Redis:

Redis kann so konfiguriert werden, dass Daten über Neustarts hinweg erhalten bleiben (Persistence)
Deine Go-App-Instanzen können ohne Datenverlust neu deployt werden

5.3. Typische Use-Cases

In-Memory in Go:

Kleine Caches innerhalb eines Requests
Kurzfristige Daten, die nur für eine Instanz relevant sind
Tests und Prototypen

Redis:

Session-Speicher (z.B. für Web-User)
Token-Storage (Access-Tokens, Refresh-Tokens, API-Keys)
Rate-Limiting (Zählung von Aufrufen pro IP/User)
Shared Cache zwischen mehreren Services

6. Schrittweise Migration: Von In-Memory zu Redis

Wenn du schon einen In-Memory-Store hast, kannst du relativ leicht auf Redis umstellen:

6.1. Gemeinsames Interface Definieren

type Store interface {
    Set(key, value string) error
    Get(key string) (string, bool, error)
}

6.2. In-Memory-Implementierung

type InMemoryStore struct {
    mu   sync.RWMutex
    data map[string]string
}

func (s *InMemoryStore) Set(key, value string) error {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.data[key] = value
    return nil
}

func (s *InMemoryStore) Get(key string) (string, bool, error) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    val, ok := s.data[key]
    return val, ok, nil
}

6.3. Redis-Implementierung, die Dasselbe Interface Erfüllt

type RedisStore struct {
    client *redis.Client
}

func (s *RedisStore) Set(key, value string) error {
    return s.client.Set(ctx, key, value, 0).Err()
}

func (s *RedisStore) Get(key string) (string, bool, error) {
    val, err := s.client.Get(ctx, key).Result()
    if err == redis.Nil {
        return "", false, nil
    }
    if err != nil {
        return "", false, err
    }
    return val, true, nil
}

6.4. Nutzung im Code

func main() {
    // Für lokale Entwicklung: InMemory
    // var store Store = &InMemoryStore{data: make(map[string]string)}

    // Für Produktion: Redis
    var store Store = NewRedisStore("localhost:6379")

    _ = store.Set("foo", "bar")
    val, ok, _ := store.Get("foo")
    if ok {
        fmt.Println("foo =", val)
    }
}

Jetzt kannst du je nach Umgebung (Dev/Prod) entscheiden, ob du In-Memory oder Redis verwendest, ohne Business-Logik zu ändern.

7. Fazit

In-Memory-Speicherung in Go ist ein guter, einfacher Einstieg – aber nur für einzelne Instanzen und nicht-kritische Daten
Mit Redis verschiebst du den Zustand aus deinem Go-Prozess in einen zentralen, gemeinsamen Speicher:
- Mehrere Instanzen können dieselben Daten sehen
- Neustarts deiner Go-Services verlieren keine wichtigen Daten
- Du bekommst Features wie TTL, Persistenz und fortgeschrittene Datentypen (Listen, Sets, Hashes, ...)

Für den nächsten Schritt kannst du ausprobieren:

Redis in Docker starten
Deine Go-App im Docker-Compose-Verbund mit Redis laufen lassen
Komplexere Strukturen in Redis nutzen (z.B. Hashes für User-Profile)

So baust du Stück für Stück von einem einfachen In-Memory-Prototypen zu einer robusteren, produktionsreifen Architektur auf.

Forem: Amin Mohammadi

Goroutines vs. OS-Threads in Go: Einfacher Leitfaden für Anfänger

1. Was sind OS Threads? (Die "Klassischen" Threads)

Ein Einfaches Beispiel mit OS Threads in Go

2. Was sind Goroutines? (Die "Leichten" Threads von Go)

Ein Einfaches Beispiel mit Goroutines

3. Der Wichtigste Unterschied: Speicherverbrauch

3.1. Test: Wie Viele OS Threads Können Wir Starten?

4. Wie Funktioniert der Go-Scheduler?

Beispiel: Blockierende Operationen

5. Praktischer Vergleich: Performance

5.1. Beispiel: Viele Zahlen Addieren

6. Wann Verwende Ich Was?

OS Threads (Direkt in Go selten nötig)

Goroutines (Das Standard-Tool in Go)

7. Ein Praktisches Beispiel: Worker Pool

8. Häufige Fehler und Tipps

Fehler 1: Goroutines ohne Synchronisation

Fehler 2: Zu Viele Goroutines

9. Zusammenfassung: Die Wichtigsten Unterschiede

10. Nächste Schritte

Fazit

Weitere Ressourcen

Einfache Datenspeicherung in Go: Von In-Memory zu Redis

Einfache Daten-Speicherung in Go: Von In-Memory zu Redis

1. In-Memory-Speicher in Go – Der Einfache Start

1.1. Ein Einfacher Speicher mit map

2. Wo In-Memory in Go zum Problem Wird

2.1. Daten Gehen beim Neustart Verloren

2.2. Skalierung mit Mehreren Instanzen

2.3. Mehr Speicherverbrauch im Go-Prozess

3. Einführung in Redis als Externe In-Memory-Datenbank

4. Go + Redis: Ein Einfaches Beispiel

4.1. Abhängigkeit Hinzufügen

4.2. Einen Einfachen Redis-Client in Go Bauen

5. Vergleich: In-Memory vs. Redis

5.1. Architektur

5.2. Neustarts und Deployments

5.3. Typische Use-Cases

6. Schrittweise Migration: Von In-Memory zu Redis

6.1. Gemeinsames Interface Definieren

6.2. In-Memory-Implementierung

6.3. Redis-Implementierung, die Dasselbe Interface Erfüllt

6.4. Nutzung im Code

7. Fazit

Weitere Ressourcen

1.1. Ein Einfacher Speicher mit `map`