Golang WebSocket连接泄漏问题分析与解决方案

1. 问题现场还原：凌晨3点的生产告警

那天凌晨3点15分，我的手机突然开始疯狂震动。打开监控系统一看，某核心服务的Goroutine数量曲线呈90度直角上升，短短10分钟内从正常水平的2000个暴涨到50000+。更可怕的是，这个数字还在以每秒数百个的速度持续增长，整个服务的响应延迟已经从平均20ms飙升到800ms以上。

第一反应是立即登录跳板机查看pprof数据。执行go tool pprof http://localhost:6060/debug/pprof/goroutine后，堆栈信息显示这些Goroutine都卡在同一个地方：

code复制50000+ goroutines blocked at:
net/http.(*persistConn).readLoop(0xc0003b2000)
    /usr/local/go/src/net/http/transport.go:2102 +0x9a
created by net/http.(*Transport).dialConn
    /usr/local/go/src/net/http/transport.go:1752 +0x8a5

这明显是HTTP连接泄漏的特征。但奇怪的是，我们的服务主要使用WebSocket协议，HTTP连接只用于健康检查。通过netstat -anp | grep ESTABLISHED进一步确认，确实有大量处于ESTABLISHED状态的TCP连接指向同一个下游服务地址。

2. 关键线索：WebSocket连接的生命周期管理

查看代码发现，问题出在WebSocket连接的重连机制上。我们的服务需要维持与下游系统的长连接，当连接断开时需要自动重连。原始实现是这样的：

go复制func connect() {
    for {
        ctx := context.Background()  // 问题点1：未使用WithCancel
        conn, _, err := websocket.Dial(ctx, "ws://downstream/service", nil)
        if err != nil {
            time.Sleep(1 * time.Second)
            continue
        }
        
        go func() {  // 问题点2：未处理goroutine退出
            for {
                msg, err := conn.Read(ctx)
                if err != nil {
                    break
                }
                // 处理消息...
            }
        }()
    }
}

这段代码存在三个致命缺陷：

1. 使用context.Background()创建不可取消的上下文
2. 重连循环没有退出条件
3. 消息读取goroutine没有回收机制

当网络出现波动时，连接会不断断开重连，但旧的goroutine由于没有收到关闭信号会一直挂起。这就解释了为什么pprof显示大量goroutine阻塞在readLoop。

3. 问题复现与根因定位

为了验证这个猜想，我在测试环境模拟了网络不稳定的场景：

bash复制# 随机丢弃50%的WebSocket数据包
sudo tc qdisc add dev eth0 root netem loss 50%

运行10分钟后，通过runtime.NumGoroutine()监控发现goroutine数量线性增长，完全复现了生产问题。使用go run main.go -memprofile=mem.pprof生成内存profile，可以看到：

code复制(pprof) list connect
Total: 1.21GB
ROUTINE ======================== main.connect
    1.21GB     1.21GB (flat, cum)   100% of Total
         .          .     58:   for {
         .          .     59:       ctx := context.Background()
    1.21GB     1.21GB     60:       conn, _, err := websocket.Dial(ctx, "ws://downstream/service", nil)
         .          .     61:       if err != nil {
         .          .     62:           time.Sleep(1 * time.Second)
         .          .     63:           continue

内存分配主要来自不断创建的连接对象，验证了资源泄漏的假设。

4. 解决方案：正确的上下文传播与资源回收

修复后的代码需要解决三个核心问题：

4.1 可取消的上下文管理

go复制func connect(stopCh <-chan struct{}) {
    for {
        ctx, cancel := context.WithCancel(context.Background())
        
        select {
        case <-stopCh:
            cancel()
            return
        default:
            conn, _, err := websocket.Dial(ctx, "ws://downstream/service", nil)
            if err != nil {
                cancel()
                time.Sleep(1 * time.Second)
                continue
            }
            // ...其余逻辑
        }
    }
}

4.2 Goroutine的优雅退出

go复制go func() {
    defer cancel()  // 确保goroutine退出时取消上下文
    
    msgCh := make(chan []byte)
    errCh := make(chan error)
    
    go func() {
        for {
            msg, err := conn.Read(ctx)
            if err != nil {
                errCh <- err
                return
            }
            msgCh <- msg
        }
    }()
    
    for {
        select {
        case <-ctx.Done():
            return
        case msg := <-msgCh:
            // 处理消息
        case err := <-errCh:
            log.Printf("read error: %v", err)
            return
        }
    }
}()

4.3 连接级别的超时控制

go复制dialCtx, dialCancel := context.WithTimeout(ctx, 5*time.Second)
defer dialCancel()

conn, _, err := websocket.Dial(dialCtx, url, nil)
if err != nil {
    return nil, fmt.Errorf("dial failed: %w", err)
}

// 设置读写超时
conn.SetReadDeadline(time.Now().Add(30 * time.Second))
conn.SetWriteDeadline(time.Now().Add(10 * time.Second))

5. 防御性编程：预防Goroutine泄漏的工程实践

5.1 监控体系建设

在init()函数中添加以下监控指标：

go复制go func() {
    for range time.Tick(10 * time.Second) {
        metrics.Gauge("runtime.goroutines", runtime.NumGoroutine())
        var m runtime.MemStats
        runtime.ReadMemStats(&m)
        metrics.Gauge("runtime.mem.heap_objects", m.HeapObjects)
    }
}()

5.2 自动化泄漏检测

使用go.uber.org/goleak在单元测试中检测泄漏：

go复制func TestConnect(t *testing.T) {
    defer goleak.VerifyNone(t)
    
    stopCh := make(chan struct{})
    defer close(stopCh)
    
    go connect(stopCh)
    time.Sleep(100 * time.Millisecond)
}

5.3 连接池化管理

对于需要大量长连接的场景，建议实现连接池：

go复制type ConnPool struct {
    mu      sync.Mutex
    conns   []*websocket.Conn
    maxSize int
}

func (p *ConnPool) Get(ctx context.Context) (*websocket.Conn, error) {
    p.mu.Lock()
    defer p.mu.Unlock()
    
    if len(p.conns) > 0 {
        conn := p.conns[0]
        p.conns = p.conns[1:]
        return conn, nil
    }
    
    return websocket.Dial(ctx, url, nil)
}

func (p *ConnPool) Put(conn *websocket.Conn) {
    p.mu.Lock()
    defer p.mu.Unlock()
    
    if len(p.conns) < p.maxSize {
        p.conns = append(p.conns, conn)
    } else {
        conn.Close()
    }
}

6. 验证与上线效果

修复方案上线后，我们进行了三项验证：

1. 压力测试：使用wrk模拟1000并发连接，持续运行1小时，goroutine数量稳定在1200±50
2. 网络模拟：通过tc工具随机断开网络，验证重连机制不会导致泄漏
3. 生产观察：灰度发布期间监控goroutine曲线，确认没有异常增长

最终指标对比：

这个案例给我的深刻教训是：在Golang中，任何go关键字的使用都必须配套考虑退出机制。就像装修时要先规划好逃生通道一样，创建goroutine前要先想好如何优雅地关闭它。