Golang中Goroutines与I/O操作详解

16个goroutine就足够了。将请求添加到任务队列。

这是一个非常好的面试问题，因为它考察了对并发模型、系统资源和I/O密集型任务之间平衡的深刻理解。你的直觉“视情况而定”和“需要进行测试”是完全正确的起点，但我们可以进一步深入，给出一个在16核机器上处理百万级HTTP请求的典型架构思路和具体实现策略。

核心原则是：利用 goroutine 的轻量级特性来管理大量 I/O 等待，但同时使用工作池（worker pool）或信号量（semaphore）来避免无限制的并发数，防止耗尽系统资源（如文件描述符、内存）或对目标服务造成拒绝服务攻击。

一个经典的实现模式是：创建数量远小于请求总数但略高于CPU核心数的“工作者 goroutine”，并通过一个缓冲通道（channel）来分发任务。

以下是一个示例代码，它演示了如何通过控制并发工作者（worker）的数量来高效、安全地发送大量请求：

package main

import (
    "context"
    "fmt"
    "net/http"
    "sync"
    "time"
)

// 任务结构体，代表一个HTTP请求
type Task struct {
    ID   int
    URL  string
    // 可以包含其他字段，如请求方法、头部、体等
}

// 结果结构体，用于收集任务执行结果
type Result struct {
    TaskID    int
    StatusCode int
    Error     error
    Duration  time.Duration
}

func main() {
    // 模拟生成100万个任务
    numTasks := 1_000_000
    tasks := make(chan Task, 1000) // 带缓冲的任务队列
    go func() {
        defer close(tasks)
        for i := 0; i < numTasks; i++ {
            tasks <- Task{ID: i, URL: "https://httpbin.org/get"}
        }
    }()

    // 关键参数：工作者（goroutine）数量
    // 对于I/O密集型任务，此数量通常设置为 CPU 核心数的若干倍（例如 2x 到 10x）。
    // 在16核机器上，可以从32或64开始测试调整。
    numWorkers := 64

    // 用于收集结果的通道
    results := make(chan Result, 1000)
    var wg sync.WaitGroup

    // 创建工作者池
    for w := 0; w < numWorkers; w++ {
        wg.Add(1)
        go worker(w, tasks, results, &wg)
    }

    // 等待所有工作者完成，然后关闭结果通道
    go func() {
        wg.Wait()
        close(results)
    }()

    // 处理结果（例如：统计、记录日志）
    successCount := 0
    for res := range results {
        if res.Error == nil && res.StatusCode == http.StatusOK {
            successCount++
        } else {
            // 处理错误或非200状态码
            // fmt.Printf("Task %d failed: %v\n", res.TaskID, res.Error)
        }
    }

    fmt.Printf("Completed. Success: %d/%d\n", successCount, numTasks)
}

func worker(id int, tasks <-chan Task, results chan<- Result, wg *sync.WaitGroup) {
    defer wg.Done()
    client := &http.Client{
        Timeout: 30 * time.Second,
    }
    for task := range tasks {
        start := time.Now()
        resp, err := client.Get(task.URL)
        duration := time.Since(start)

        res := Result{
            TaskID: task.ID,
            Duration: duration,
        }
        if err != nil {
            res.Error = err
        } else {
            res.StatusCode = resp.StatusCode
            resp.Body.Close() // 重要：及时关闭响应体
        }
        results <- res
    }
}

关键点解析：

1. 工作者数量 (numWorkers)：这是问题的核心。对于纯I/O密集型任务（如HTTP请求，大部分时间在等待网络），goroutine 在等待时会被调度器挂起，让出CPU。因此，我们可以运行比CPU核心数多得多的 goroutine。在16核机器上，设置 32 到 256 个工作者是一个合理的起始范围。最佳值需要通过压测确定，目标是让CPU利用率保持在高位（如70%-80%），同时观察内存增长和网络延迟是否在可接受范围。
2. 任务队列 (tasks chan)：使用缓冲通道作为任务队列。这解耦了任务生成和任务执行，使得工作者可以按自己的速度消费任务，避免了生产者被阻塞。
3. 资源管理：
   • 每个工作者使用独立的 http.Client 或共享一个（需注意并发安全），并设置合理的超时（Timeout）。
   • 必须关闭响应体 (resp.Body.Close())，否则会导致 goroutine 泄漏和文件描述符耗尽。
   • 通过 sync.WaitGroup 优雅地等待所有工作者结束。
4. 结果处理：使用单独的 results 通道收集结果，避免在工作者中直接进行复杂的处理（如写入数据库），以免阻塞工作者。如果结果处理也很耗时，可以考虑使用另一组工作者来处理结果。

进阶优化：

• 连接池：Go 的 net/http 默认启用了连接池（通过 DefaultTransport）。确保使用同一个 http.Client 实例（或共享其 Transport）可以高效复用TCP连接，极大提升性能。
• 上下文（Context）：为整个批量操作和每个请求设置上下文，以便支持超时和取消。
• 限速/背压：如果目标服务器有速率限制，可以使用 golang.org/x/time/rate 库或带缓冲的通道实现令牌桶进行限流。
• 错误重试：在工作者逻辑中加入简单的指数退避重试机制，提高鲁棒性。

结论： 对于“16核机器发送100万请求”这个问题，一个专业且具体的回答是：“我会实现一个固定大小的 goroutine 工作池，池的大小并非直接等于CPU核心数，而是根据任务特性进行设置。对于网络I/O密集型任务，我会从 64 或 128 个工作者 goroutine 开始进行性能测试，同时配合缓冲通道来分发任务。通过监控系统资源（CPU、内存、网络连接数）和请求延迟，动态调整工作者数量，找到吞吐量最大且资源消耗稳定的最佳并发度。核心是避免创建百万个即时并发goroutine，而是让有限的工作者持续不断地处理队列中的任务。”