Understanding Go Goroutine and Channel: Usage, Pitfalls, and Deadlock Diagnosis

Introduction Go's biggest feature is native support for concurrency; goroutines are lightweight and efficient, and channels enable communication between them. Beginners often encounter the fatal error all goroutines are asleep - deadlock!. This article starts from basic usage, explains channel characteristics, common deadlock scenarios, and graceful goroutine exit methods.

1. Goroutine Basics and the go Keyword

The go keyword starts a goroutine. Goroutines are scheduled by the Go runtime, not OS threads, and consume very little resources, allowing thousands to run concurrently.

package main

import ("fmt" "time")

func hello() {
    fmt.Println("hello goroutine")
}

func main() {
    go hello() // start goroutine
    time.Sleep(100 * time.Millisecond) // wait for goroutine
    fmt.Println("main over")
}

Key pitfall: When main returns, all goroutines are forcibly terminated; they are not waited for. Using time.Sleep to wait is unreliable for production code—use channels or sync.WaitGroup instead.

2. Channel

A channel is a pipe for data exchange between goroutines. Channels come in two forms: unbuffered and buffered.

Declaration syntax :

// Unbuffered channel
ch1 := make(chan int)

// Buffered channel with capacity 3
ch2 := make(chan int, 3)

Send, receive, close :

ch <- 10          // send
val := <-ch       // receive
val, ok := <-ch  // receive with close detection
close(ch)        // close channel

Three receive forms:

val, ok := <-quitCh          // full form
val := <-quitCh               // ignore ok
<-quitCh                      // discard value, only wait for event

The ok flag indicates whether the received value is valid; ok == false means the channel is closed and empty.

Iterating with for:

for {
    item, ok := <-ch4
    if !ok { break }
    fmt.Printf("Received: %s
", item)
}

Using for range automatically handles the ok check and breaks when the channel is closed:

for item := range ch4 {
    fmt.Printf("Received: %s
", item)
}

Close Rules (high‑frequency interview topic)

Only close a non‑nil, already created channel; closing a nil channel panics.

Closing the same channel twice panics.

After a channel is closed you can still read remaining buffered data; further reads return the zero value with ok == false.

Sending to a closed channel panics.

ch := make(chan int, 2)
ch <- 1 // non‑blocking
ch <- 2 // non‑blocking
ch <- 3 // blocks, buffer full

Closing a channel:

fmt.Println("
=== 4. Close Channel ===")
ch3 := make(chan string, 2)
ch3 <- "🍎"
ch3 <- "🍊"
close(ch3) // cannot send after this
fmt.Printf("  Receive: %s
", <-ch3) // 🍎
fmt.Printf("  Receive: %s
", <-ch3) // 🍊
val, ok := <-ch3
fmt.Printf("  Receive again: %q, ok=%v
", val, ok) // "", false

3. Core Distinction: Blocking ≠ Deadlock

Blocking is a normal state where a goroutine waits for data; deadlock occurs only when all goroutines are blocked, causing the runtime to panic with all goroutines are asleep - deadlock.

Two scenarios illustrate the difference:

Scenario A : Main blocks on receive, but another goroutine will send later – only blocking, no deadlock.

Scenario B : Main blocks on receive and no other goroutine exists – deadlock.

4. Common Deadlock Situations

Unbuffered channel with send and receive in the same goroutine – deadlock.

Buffered channel full, same goroutine continues sending – deadlock.

Main waits on a channel while a child goroutine exits without sending or closing – deadlock.

Two goroutines waiting on each other (circular wait) – deadlock.

Range over a channel without closing it – the loop never exits, leading to deadlock.

Using select with a nil channel – the nil case blocks forever.

Example of a nil channel in select:

var ch chan int // nil
select {
case <-ch:
    // blocks forever
case ch <- 1:
    // blocks forever
default:
    fmt.Println("default case")
}

5. Graceful Goroutine Exit Methods

5.1 Close a channel and use for‑range to detect exit

func main() {
    ch := make(chan struct{})
    go func() {
        for {
            select {
            case <-ch:
                fmt.Println("exit signal received")
                return
            default:
                fmt.Println("working...")
                time.Sleep(200 * time.Millisecond)
            }
        }
    }()
    time.Sleep(1 * time.Second)
    close(ch) // send exit signal
    time.Sleep(300 * time.Millisecond)
}

5.2 Context‑controlled cancellation (common in production)

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()
    go func(ctx context.Context) {
        for {
            select {
            case <-ctx.Done():
                fmt.Println("ctx triggered exit, err:", ctx.Err())
                return
            default:
                fmt.Println("business work")
                time.Sleep(200 * time.Millisecond)
            }
        }
    }(ctx)
    time.Sleep(2 * time.Second)
}

5.3 Combine channel and context

func worker(ctx context.Context, dataChan chan int) {
    for {
        select {
        case <-ctx.Done():
            // clean up
            return
        case data := <-dataChan:
            // process data
            process(data)
        }
    }
}

6. Waiting for Goroutine Completion

6.1 time.Sleep (not recommended)

Sleep does not guarantee the child goroutine finishes; if the sleep is too short the program exits early, if too long it wastes time.

6.2 Channel synchronization (simple case)

func main() {
    ch := make(chan struct{})
    go func() {
        defer close(ch)
        fmt.Println("subtask running")
    }()
    <-ch // block until subtask signals
    fmt.Println("all done")
}

6.3 sync.WaitGroup (preferred for multiple goroutines)

var wg sync.WaitGroup
for i := 0; i < 5; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        task()
    }()
}
wg.Wait() // blocks until counter reaches zero

7. Summary

Goroutine lifetimes are not tied to main; main exiting kills all running goroutines.

Unbuffered channels require send and receive in different goroutines; buffered channels need attention to capacity.

Close‑channel rules: never close nil, never close twice, never send after close.

When ranging over a channel, remember to close it to avoid deadlock. select can monitor multiple channels; a nil channel blocks forever.

Prefer graceful shutdown via closing channels or context cancellation rather than killing goroutines.

Deadlock happens only when every goroutine is blocked with no progress possible.