Gin 框架中的并发处理和 goroutine 管理是什么?

Gin 框架中如何处理并发请求？

Gin 基于 Go 标准库 net/http 构建，每一个 HTTP 请求都会由 Go 的 HTTP Server 自动分配一个独立的 goroutine 来处理。这意味着 Gin 本身就是并发安全的——不同请求之间不会互相阻塞。但当你需要在请求处理过程中自己启动额外的 goroutine 时，就需要格外小心了。

核心问题在于：Gin 使用 sync.Pool 复用 gin.Context 对象。当 handler 函数返回后，Context 会被回收到池中，可能被下一个请求复用。如果你在子 goroutine 中直接引用原始 Context，就会出现数据竞争甚至 panic。

在 handler 中启动 goroutine 时为什么必须用 c.Copy()？

先看一段有问题的代码：

go
func handler(c *gin.Context) {
    go func() {
        // 危险！handler 返回后 c 可能已被回收复用
        log.Println(c.Request.URL.Path)
    }()
    c.JSON(200, gin.H{"status": "ok"})
}

这段代码在并发量大时几乎必出问题。正确做法是调用 c.Copy() 创建一个只读副本：

go
func handler(c *gin.Context) {
    cCopy := c.Copy()
    go func() {
        // 安全：使用副本，不受原始 Context 回收影响
        log.Println(cCopy.Request.URL.Path)
    }()
    c.JSON(200, gin.H{"status": "ok"})
}

c.Copy() 会复制 Request、Keys 等字段，保证子 goroutine 读取的数据不会因为请求结束而被篡改。这是 Gin 官方文档明确要求的做法。

如何控制 goroutine 的并发数量？

如果不加限制地在每个请求中启动 goroutine，高并发时 goroutine 数量会暴涨，导致内存飙升、调度延迟增大。控制并发数的常用方式有两种。

用带缓冲 channel 实现信号量

go
func MaxAllowed(n int) gin.HandlerFunc {
    sem := make(chan struct{}, n)
    return func(c *gin.Context) {
        sem <- struct{}{}
        defer func() { <-sem }()
        c.Next()
    }
}

// 注册为中间件，限制同时处理的请求不超过 100
r := gin.Default()
r.Use(MaxAllowed(100))

channel 的缓冲大小就是最大并发数。请求进来时写入 channel（缓冲满则阻塞），处理完毕后读出释放位置。

用 golang.org/x/time/rate 做令牌桶限流

信号量控制的是并发数，而令牌桶控制的是每秒请求数（QPS）：

go
import "golang.org/x/time/rate"

var limiter = rate.NewLimiter(100, 10) // 每秒 100 个请求，突发上限 10

func rateLimitMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        if !limiter.Allow() {
            c.JSON(429, gin.H{"error": "too many requests"})
            c.Abort()
            return
        }
        c.Next()
    }
}

两者经常搭配使用：信号量限制同时在跑的 goroutine 数量，令牌桶限制请求进入的速率。

Worker Pool 模式怎么用？

当需要处理大量同类任务（比如批量发邮件、批量调用第三方接口）时，逐个启动 goroutine 既不可控也不高效。Worker Pool 预先创建固定数量的 worker goroutine，通过 channel 分发任务：

go
type Job struct {
    ID      int
    Payload interface{}
}

type Result struct {
    JobID  int
    Output interface{}
    Err    error
}

func newWorkerPool(numWorkers int, jobCh <-chan Job, resultCh chan<- Result) {
    for i := 0; i < numWorkers; i++ {
        go func(workerID int) {
            for job := range jobCh {
                out, err := processJob(job)
                resultCh <- Result{JobID: job.ID, Output: out, Err: err}
            }
        }(i)
    }
}

在 Gin 中的典型用法：将 Worker Pool 作为应用级单例初始化，handler 只负责往 jobCh 投递任务：

go
var (
    jobCh    = make(chan Job, 1000)
    resultCh = make(chan Result, 1000)
)

func init() {
    newWorkerPool(20, jobCh, resultCh)
}

func handleJob(c *gin.Context) {
    job := Job{ID: 1, Payload: c.Query("data")}
    jobCh <- job

    select {
    case res := <-resultCh:
        c.JSON(200, gin.H{"result": res.Output})
    case <-time.After(5 * time.Second):
        c.JSON(504, gin.H{"error": "timeout"})
    }
}

Worker Pool 的好处：goroutine 数量固定可控，任务通过 channel 排队，不会因为瞬时流量激增而崩溃。生产环境也可以考虑使用成熟的协程池库如 ants，它支持动态扩缩容和任务超时。

多个 goroutine 之间如何安全地共享数据？

Go 的哲学是"不要通过共享内存来通信，而要通过通信来共享内存"——优先用 channel。但有些场景确实需要共享状态，这时需要加锁或使用并发安全的容器。

sync.Map：适合读多写少

go
var cache sync.Map

func handleCache(c *gin.Context) {
    key := c.Query("key")
    if val, ok := cache.Load(key); ok {
        c.JSON(200, gin.H{"value": val})
        return
    }
    val := computeValue(key)
    cache.Store(key, val)
    c.JSON(200, gin.H{"value": val})
}

sync.Map 对读多写少的场景做了优化，不需要额外加锁。但如果是写操作频繁的场景，它的性能反而不如 map + Mutex。

sync.Mutex：适合写操作频繁

go
type SafeCounter struct {
    mu sync.Mutex
    m  map[string]int
}

func (sc *SafeCounter) Incr(key string) {
    sc.mu.Lock()
    sc.m[key]++
    sc.mu.Unlock()
}

func (sc *SafeCounter) Get(key string) int {
    sc.mu.Lock()
    defer sc.mu.Unlock()
    return sc.m[key]
}

面试中常考的点：Mutex 和 RWMutex 的区别。如果读远多于写，用 sync.RWMutex 可以让多个读操作并行，提升吞吐。

如何等待多个 goroutine 完成并收集结果？

sync.WaitGroup 是标准库提供的同步原语，用来等待一组 goroutine 全部结束：

go
func handleConcurrentTasks(c *gin.Context) {
    var wg sync.WaitGroup
    results := make([]string, 0, 3)
    mu := sync.Mutex{}

    tasks := []string{"task1", "task2", "task3"}
    for _, task := range tasks {
        wg.Add(1)
        go func(t string) {
            defer wg.Done()
            res := processTask(t)
            mu.Lock()
            results = append(results, res)
            mu.Unlock()
        }(task)
    }

    wg.Wait()
    c.JSON(200, gin.H{"results": results})
}

注意这里对 results 切片的追加操作加了锁，因为多个 goroutine 并发 append 会导致数据竞争。另一个常见做法是用 channel 收集结果，避免加锁。

如何用 context 取消正在执行的 goroutine？

生产环境中，客户端可能随时断开连接，或者请求有超时要求。这时需要通过 context.Context 通知子 goroutine 提前退出：

go
func handleCancellableTask(c *gin.Context) {
    ctx, cancel := context.WithTimeout(c.Request.Context(), 3*time.Second)
    defer cancel()

    resultCh := make(chan string, 1)
    go func() {
        resultCh <- longRunningTask(ctx)
    }()

    select {
    case res := <-resultCh:
        c.JSON(200, gin.H{"result": res})
    case <-ctx.Done():
        c.JSON(408, gin.H{"error": "request timeout"})
    }
}

func longRunningTask(ctx context.Context) string {
    for i := 0; i < 10; i++ {
        select {
        case <-ctx.Done():
            return "cancelled"
        default:
            time.Sleep(500 * time.Millisecond)
        }
    }
    return "completed"
}

关键点：在循环或耗时步骤中检查 ctx.Done()，一旦 context 被取消就能及时退出，避免 goroutine 泄漏。

如何检测和防止 goroutine 泄漏？

goroutine 泄漏是 Go 服务中最隐蔽的问题之一——goroutine 不会自动报错，只会默默占用内存，直到 OOM。

常见泄漏场景

1. channel 阻塞：往无缓冲 channel 写入，但没有接收方；或从 channel 读取，但没有发送方
2. 缺少退出机制：goroutine 内部是死循环，没有监听退出信号
3. context 未传递：启动 goroutine 时没有传入 context，无法通知其退出

检测手段

go
import _ "net/http/pprof"

// 在 main 中启动 pprof HTTP 服务
go func() {
    http.ListenAndServe(":6060", nil)
}()

然后访问 http://localhost:6060/debug/pprof/goroutine?debug=1 可以看到当前所有 goroutine 的堆栈。对比两次请求的 goroutine 数量，如果持续增长就说明存在泄漏。Gin 项目也可以用 github.com/gin-contrib/pprof 直接集成。

防泄漏原则

• 启动 goroutine 时就想好它什么时候结束
• 所有 goroutine 都应该监听 context 的取消信号
• 用 defer 确保资源释放和 channel 关闭
• 上线前用 go test -race 检测数据竞争

面试中常被追问的几个问题

Gin 为什么用 sync.Pool 管理 Context？ 高并发下每个请求都 new 一个 Context 会给 GC 带来巨大压力。sync.Pool 让 Context 对象在请求结束后被复用，减少内存分配次数。这也是为什么在 goroutine 中不能直接用原始 Context——它随时会被回收。

goroutine 和线程的区别？ goroutine 是用户态的轻量级协程，初始栈只有 2KB（可动态扩容），创建和切换成本远低于操作系统线程。一个 Go 进程可以轻松跑几十万个 goroutine，而线程通常受限于系统资源只能开几千个。

GMP 调度模型和 Gin 并发有什么关系？ Gin 的每个请求对应一个 G（goroutine），由 Go runtime 的 GMP 模型调度到 M（系统线程）上执行。P（逻辑处理器）的数量默认等于 CPU 核心数，决定了真正的并行度。理解 GMP 有助于排查调度延迟和 CPU 利用率问题。