如何处理Goroutine执行超时？解决任务阻塞的资源泄漏问题

一、为什么Context无法让任务退出？ #

你的代码里，Task只是单纯执行time.Sleep(3600*time.Second)，完全没有监听Context的取消信号。Context的超时/取消是协作式的——它只会发送一个取消通知，需要任务主动去检查这个通知并终止执行。如果任务不处理ctx.Done()通道，Context超时后任务会继续阻塞，Goroutine也不会被回收，自然会导致资源泄漏。

二、修复代码的具体步骤 #

要解决这个问题，需要让Task响应Context，同时确保超时后正确释放所有资源（WaitGroup计数、Worker槽位）。以下是修改后的完整代码：

package main

import (
    "context"
    "fmt"
    "math/rand"
    "runtime"
    "sync"
    "time"
)

type Task func(ctx context.Context)

type MultiWork struct {
    Works chan Task
    Limit chan struct{}
    Wg    sync.WaitGroup
}

func NewMultiWork(workers int) *MultiWork {
    nm := &MultiWork{
        Works: make(chan Task),
        Limit: make(chan struct{}, workers),
    }

    go func() {
        for task := range nm.Works {
            nm.Limit <- struct{}{}

            nm.Wg.Add(1)
            go func(task Task) {
                defer func() {
                    <-nm.Limit // 无论任务成功还是超时，都释放Worker槽位
                }()

                ctx, cancel := context.WithTimeout(context.Background(), time.Second*2)
                defer cancel() // 确保Context被取消，避免内存泄漏

                task(ctx)
            }(task)
        }
    }()

    return nm
}

func main() {
    rand.Seed(time.Now().UnixNano())

    nm := NewMultiWork(10)

    task := func(ctx context.Context) {
        defer nm.Wg.Done()
        // 用select监听Context取消信号，同时执行Sleep
        select {
        case <-ctx.Done():
            fmt.Println("task timeout or canceled", rand.Intn(1000))
            return
        case <-time.After(time.Second * 3600):
            fmt.Println("task finished ", rand.Intn(1000))
        }
    }

    for range [100]struct{}{} {
        nm.Works <- task
    }

    close(nm.Works) // 先关闭任务通道，让消费者Goroutine退出
    nm.Wg.Wait()    // 等待所有任务完成

    i := 25
    for i > 0 {
        fmt.Println("gn = ", runtime.NumGoroutine())
        i--
        time.Sleep(time.Second * 1)
    }
}

关键修改点： #

• Task响应Context：用select同时监听ctx.Done()和time.After()，一旦Context超时，立刻退出任务。
• 资源安全释放：把<-nm.Limit放到defer里，确保无论任务是正常完成还是超时，都能释放Worker槽位，避免Limit通道被永久占用。
• 调整关闭顺序：先关闭Works通道，再调用Wg.Wait()，避免主Goroutine阻塞在Wait()时，任务发送通道已经关闭导致panic。

三、其他可行处理方案 #

如果你的Task是调用第三方库的阻塞函数（无法修改其内部逻辑来响应Context），可以尝试以下方案：

1. 用Goroutine包裹任务，超时后强制退出 #

注意：runtime.Goexit()会终止当前Goroutine，但不会影响其他Goroutine，不过要确保任务没有持有未释放的资源（比如文件句柄、锁），否则可能导致资源泄漏。示例：

task := func(ctx context.Context) {
    defer nm.Wg.Done()
    done := make(chan struct{})
    go func() {
        // 第三方阻塞函数
        time.Sleep(time.Second * 3600)
        close(done)
    }()

    select {
    case <-ctx.Done():
        fmt.Println("task forced exit")
        runtime.Goexit() // 终止当前Goroutine
    case <-done:
        fmt.Println("task finished")
    }
}

2. 使用带超时的工作池封装 #

可以用errgroup结合Context来管理一组任务的生命周期，简化超时控制：

import "golang.org/x/sync/errgroup"

// 示例：用errgroup管理带超时的任务
func main() {
    g, ctx := errgroup.WithContext(context.Background())
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()

    for i := 0; i < 100; i++ {
        g.Go(func() error {
            select {
            case <-ctx.Done():
                return ctx.Err()
            case <-time.After(3600*time.Second):
                fmt.Println("task done")
                return nil
            }
        })
    }

    if err := g.Wait(); err != nil {
        fmt.Println("tasks canceled due to timeout:", err)
    }
}

3. 资源隔离（极端场景） #

如果任务是CPU密集型或会占用大量资源，且无法通过协作式取消终止，可以考虑将任务放到独立的进程中执行，超时后杀死进程。这种方案开销较大，仅适用于无法用Goroutine协作取消的场景。

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