Go 微服务并发调优实战：Goroutine、Channel 与 Context

select {
case result := <-ch:
    // 成功处理
case <-time.After(100 * time.Millisecond):
    return errors.New("timeout")
default:
    // 非阻塞尝试
}

如果这类 Channel 操作会出现在请求链路里，我更倾向于给它加超时，而不是指望它永远顺滑。没有退出口的协程，迟早会把系统拖慢。

三、Context 传递：取消信号要一路带下去

context.Context 的作用很单纯：把超时、取消、截止时间这些控制信号往下传。它不是装饰品，很多并发问题其实都是因为这里断了。

该守的几个原则

1. 函数入参里带上 Context：

func Process(ctx context.Context, id string) error { ... }

2. 向下游传原始 ctx，不要随手新建一个；
3. 协程里监听 ctx.Done()：

select {
case <-ctx.Done():
    return ctx.Err() // context canceled or deadline exceeded
case result := <-ch:
    // handle
}

HTTP 调用和数据库查询里尤其要注意

func HandleRequest(w http.ResponseWriter, r *http.Request) {
    // r.Context() 自带 server 侧的超时和取消信号
    result, err := callExternalService(r.Context())
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    w.Write(result)
}

func callExternalService(ctx context.Context) ([]byte, error) {
    req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil)
    client := &http.Client{}
    resp, err := client.Do(req)
    // ...
}

Context 是树状传播的，父节点一取消，下面整棵子树都会收到信号。这个特性很有用，但前提是你真的把它传下去了。

四、连接池：数据库和 HTTP Client 都别反复新建

高并发场景里，频繁创建连接通常不是什么'灵活'，而是性能负担。数据库和 HTTP Client 都应该复用。

1. database/sql 的连接池

db, _ := sql.Open("mysql", dsn)
db.SetMaxOpenConns(100)       // 最大连接数
db.SetMaxIdleConns(10)        // 最大空闲数
db.SetConnMaxLifetime(30 * time.Minute) // 连接最大生命周期

设置这几个参数时，别只盯着应用侧。数据库能扛多少、连接是否会堆积，才是更实在的边界。MaxOpenConns 通常要结合 DB 的承载能力来定，MaxIdleConns 也别放太大，空闲连接不是越多越好。

2. HTTP Client 复用

// 全局复用 client
var httpClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns: 100,
        MaxIdleConnsPerHost: 10,
        IdleConnTimeout: 90 * time.Second,
    },
    Timeout: 30 * time.Second,
}

这块最容易踩的坑就是：每次请求都 new 一个 http.Client。短时间看不出什么，流量一高，端口和连接状态就会开始给你颜色看。复用客户端，通常是更省事的做法。

五、怎么设计可复现的并发问题

调优不是只靠'感觉像有问题'。能复现，才好查，才好验证修复是否真的生效。下面这些场景不复杂，但很适合拿来做排查和回归。

1. Goroutine 死锁

// 两个 Goroutine 互相等待
ch1, ch2 := make(chan bool), make(chan bool)
go func() {
    <-ch1
    ch2 <- true
}()
go func() {
    <-ch2
    ch1 <- true
}()
// 无任何写入，永久阻塞

2. Channel 阻塞

ch := make(chan int) // 无缓冲
go func() {
    ch <- 1
}() // 无 receiver，Goroutine 挂起
time.Sleep(time.Second) // pprof 可见一个 Goroutine 卡在 ch <- 1

3. CGO 内存异常

• 调用 C 函数后没有正确释放内存；
• Go 的 GC 处理不到 C 分配的内存；
• 可以结合 runtime.MemStats 或 pprof/heap 看内存是不是在持续增长。

如果要做评估，我会看三件事：能不能用 pprof 找到卡住的 goroutine，能不能用 select + timeout 或 Context 把问题收回来，以及能不能用不打扰业务的方式把异常暴露出来，比如定期 dump goroutine 数量。

六、Go 并发控制流程图

下面这张图把 HTTP 请求里的 Context、Channel、Goroutine 关系画得比较清楚：

图里最核心的意思其实就两个：Context 负责统一控制超时和取消；多个 goroutine 并行干活，结果通过 Channel 汇总，select 再把超时和正常返回接住。这样资源该回收的时候能回收，不会一直挂在那儿。

结语

Go 的并发模型确实顺手，但顺手不等于可以随便用。Goroutine 不是线程，Channel 也不是万能队列，Context 更不是可有可无的参数。

高并发微服务真正要做的，不是把协程开得更多，而是在压力上来时还能稳住、还能看清、还能收回来。最实用的几个点其实也不复杂：每个并发操作都要有退出机制，资源尽量复用，异常要能定位和复现。做到这些，服务一般就不会太差。