技术问询：本应永久运行的Go协程被终止的可能场景

Hey there! Let's walk through all the ways a Go goroutine can terminate, with a special focus on those cases where you thought your goroutine would run indefinitely—only to find it stopped unexpectedly.

Normal Goroutine Termination (Expected Cases) #

These are the scenarios where a goroutine finishes exactly as you planned:

• The goroutine completes all its code execution: For example, a simple function like func() { fmt.Println("Done!") } runs once and exits.
• The goroutine explicitly returns: Any return statement (even in a loop, if a condition triggers it) will end the goroutine.

Unexpected Termination of "Permanent" Goroutines (The Tricky Ones) #

This is where things usually go wrong when you intended a goroutine to run forever. Let's break down each common case:

1. Main Goroutine Exits #

The moment the main goroutine finishes (either via main() returning or calling os.Exit()), the entire Go process exits—all other goroutines are abruptly terminated, no matter what they were doing. This is one of the most common gotchas for new Go developers.

Example:

func main() {
    // Start a goroutine that's supposed to run forever
    go func() {
        for {
            fmt.Println("Running...")
            time.Sleep(1 * time.Second)
        }
    }()
    // Main exits after 2 seconds, killing the background goroutine
    time.Sleep(2 * time.Second)
}

2. Unrecovered Panic #

If a goroutine encounters a panic (like a nil pointer dereference, out-of-bounds slice access, or explicit panic() call) and there's no recover() within the goroutine's call stack, the goroutine will crash and terminate. Unlike the main goroutine, a panic in a child goroutine won't take down the entire program—but it will stop that specific goroutine cold.

Example:

func main() {
    go func() {
        for {
            fmt.Println("Working...")
            // Accidental nil dereference triggers a panic
            var ptr *int
            fmt.Println(*ptr) // This line will panic
            time.Sleep(1 * time.Second)
        }
    }()
    time.Sleep(5 * time.Second)
}

Here, the goroutine runs once, panics, and terminates—even though you intended it to loop forever.

3. Closed Channel (with Range Loop Exhaustion) #

If your "permanent" goroutine uses a for val := range ch loop to process data from a channel, it will exit automatically when:

• The channel is closed, and all values sent on the channel have been received.

This is a common issue if the producer of the channel exits unexpectedly and closes the channel, or if you accidentally close the channel elsewhere.

Example:

func main() {
    ch := make(chan int)
    // Consumer goroutine supposed to run forever
    go func() {
        for num := range ch {
            fmt.Println("Received:", num)
        }
        fmt.Println("Consumer goroutine exited!") // Runs when ch is closed
    }()
    // Producer sends values then closes the channel
    for i := 0; i < 3; i++ {
        ch <- i
    }
    close(ch)
    time.Sleep(1 * time.Second)
}

The consumer exits once the channel is closed and all values are read, even though you intended it to keep waiting for more data.

4. Context Cancellation #

If your goroutine listens to a context.Context's Done() channel, it will terminate when the context is canceled (either via cancel() being called, a timeout, or a deadline expiring). This is intentional for graceful shutdowns—but can be accidental if the context is canceled prematurely.

Example:

func main() {
    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()

    go func(ctx context.Context) {
        for {
            select {
            case <-ctx.Done():
                fmt.Println("Goroutine terminated due to context cancel")
                return
            default:
                fmt.Println("Running...")
                time.Sleep(1 * time.Second)
            }
        }
    }(ctx)

    // Accidentally cancel the context early
    time.Sleep(3 * time.Second)
    cancel()
    time.Sleep(1 * time.Second)
}

Here, the goroutine exits when cancel() is called—even if you meant for it to run until the program ends.

5. Synchronization Primitive Completion #

If your goroutine is waiting on a synchronization primitive like sync.WaitGroup or sync.Cond, it will proceed once that primitive is satisfied, and if there's no subsequent loop to keep it running, the goroutine will exit.

Example with WaitGroup:

func main() {
    var wg sync.WaitGroup
    wg.Add(2)

    // Goroutine supposed to run forever, but waits for WaitGroup
    go func() {
        wg.Wait()
        fmt.Println("WaitGroup done—goroutine exiting")
        // No loop here, so it exits immediately after Wait() returns
    }()

    // Two worker goroutines that call Done()
    go func() {
        defer wg.Done()
        time.Sleep(2 * time.Second)
    }()
    go func() {
        defer wg.Done()
        time.Sleep(3 * time.Second)
    }()

    time.Sleep(4 * time.Second)
}

The monitoring goroutine exits as soon as the WaitGroup count hits zero, even though you might have intended it to keep running.

6. Blocked on a Never-Ready Operation (Stuck, Not Terminated) #

While this isn't termination, it's worth mentioning: if a goroutine blocks on an operation that will never complete (like reading from a channel that no one will send to, or waiting on a mutex that's never unlocked), it will hang indefinitely—but it won't terminate. The only way it stops is if the entire program exits.

内容的提问来源于stack exchange，提问作者Aakash Goyal