优化Go并发HTTP客户端：避免因错误处理不当导致的程序挂起与内存激增-Golang-PHP中文网

优化Go并发HTTP客户端：避免因错误处理不当导致的程序挂起与内存激增

本文深入探讨了go语言并发http客户端中一个常见的陷阱：由于不完善的错误处理和通道机制，可能导致程序挂起及内存激增。通过分析一个实际案例，我们揭示了`http.get`错误处理不足如何引发通道死锁，并提供了一种健壮的解决方案，确保并发请求计数准确无误，从而构建稳定高效的http客户端。

并发HTTP客户端的挑战与现象

在Go语言中构建高性能的并发HTTP客户端是常见需求，例如用于压力测试或数据抓取。一个常见的实现模式是启动多个Goroutine并发发送请求，并通过通道（channel）收集结果。然而，如果对HTTP请求的错误处理不当，这种模式可能导致程序出现意料之外的行为，例如程序挂起、内存占用异常飙升。

考虑以下Go语言并发HTTP客户端的简化实现，旨在模拟ab工具的功能：

package main

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

type Result struct {
    successful int
    total      int
    timeouts   int
    errors     int
    duration   time.Duration
}

func makeRequests(url string, messages int, resultChan chan<- *http.Response) {
    for i := 0; i < messages; i++ {
        resp, _ := http.Get(url) // 忽略了错误返回值
        if resp != nil {
            resultChan <- resp
        }
    }
}

func deployRequests(url string, threads int, messages int) *Result {
    results := new(Result)
    resultChan := make(chan *http.Response) // 非缓冲通道
    start := time.Now()
    defer func() {
        results.duration = time.Since(start)
        fmt.Printf("总耗时: %s\n", results.duration)
    }()

    for i := 0; i < threads; i++ {
        go makeRequests(url, (messages/threads)+1, resultChan)
    }

    // 循环接收结果，直到总数达到预期
    for response := range resultChan {
        if response.StatusCode != 200 {
            results.errors += 1
        } else {
            results.successful += 1
        }
        results.total += 1
        if results.total == messages {
            return results
        }
    }
    return results
}

func main() {
    results := deployRequests("http://www.google.com", 10, 1000)
    fmt.Printf("总请求数: %d\n", results.total)
    fmt.Printf("成功请求数: %d\n", results.successful)
    fmt.Printf("错误请求数: %d\n", results.errors)
    fmt.Printf("超时请求数: %d\n", results.timeouts)
}

登录后复制

当messages参数较小（例如100）时，上述代码可能正常运行。然而，一旦messages增加（例如1000），程序就可能出现挂起，并通过htop观察到进程的虚拟内存（VIRT）飙升至数百GB。

根本原因剖析：通道死锁与请求计数失衡

这种异常行为的根本原因在于Go语言的并发模型、通道机制以及不完善的错误处理共同作用下导致的死锁。

http.Get的错误返回值被忽略：在makeRequests函数中，resp, _ := http.Get(url)这一行忽略了http.Get可能返回的错误。当网络不稳定、目标服务器拒绝连接、请求超时等情况发生时，http.Get会返回一个非nil的error值，同时resp会是nil。
条件发送到通道：makeRequests函数仅在resp != nil时才将响应发送到resultChan。这意味着，如果一个HTTP请求因错误而导致resp为nil，那么这个请求的结果将不会被发送到resultChan。
请求计数失衡导致死锁：deployRequests函数中的for response := range resultChan循环会一直尝试从resultChan接收数据，并期望最终results.total能达到messages。如果因为部分请求失败（resp为nil）而没有发送到通道，那么resultChan接收到的消息总数将少于messages。这导致results.total == messages的条件永远无法满足，deployRequests函数将无限期地等待在resultChan上，从而造成程序挂起。
非缓冲通道的影响：resultChan是一个非缓冲通道（make(chan *http.Response)）。非缓冲通道的发送和接收操作是同步的，即发送方会阻塞直到有接收方准备好接收，反之亦然。虽然这并非导致死锁的直接原因，但在请求发送量大、接收处理慢的情况下，如果所有Goroutine都因发送阻塞而无法继续，也可能加剧问题。

解决方案：完善错误处理与通道通信

为了解决上述问题，核心思想是确保每一个“逻辑请求”都对应一个发送到resultChan的消息，无论该请求成功与否。我们可以通过发送nil响应来表示请求失败。

1. 修改 makeRequests 函数

makeRequests函数需要调整为，即使http.Get返回错误，也要向resultChan发送一个nil值，以表明该次请求已“完成”但失败。

吐槽大师

吐槽大师（Roast Master） - 终极 AI 吐槽生成器，适用于 Instagram，Facebook，Twitter，Threads 和 Linkedin

查看详情

func makeRequests(url string, messages int, resultChan chan<- *http.Response) {
    for i := 0; i < messages; i++ {
        resp, err := http.Get(url) // 获取错误返回值
        if err != nil {
            resultChan <- nil // 请求失败，发送nil响应
        } else {
            resultChan <- resp // 请求成功，发送实际响应
        }
    }
}

登录后复制

2. 修改 deployRequests 函数

deployRequests函数在接收到nil响应时，应将其计为错误。

func deployRequests(url string, threads int, messages int) *Result {
    results := new(Result)
    resultChan := make(chan *http.Response)
    start := time.Now()
    defer func() {
        results.duration = time.Since(start)
        fmt.Printf("总耗时: %s\n", results.duration)
    }()

    for i := 0; i < threads; i++ {
        go makeRequests(url, (messages/threads)+1, resultChan)
    }

    for response := range resultChan {
        results.total += 1 // 无论成功失败，都计入总数
        if response == nil { // 检查是否为nil响应，表示请求失败
            results.errors += 1
        } else if response.StatusCode != 200 {
            results.errors += 1
        } else {
            results.successful += 1
        }

        if results.total == messages {
            return results
        }
    }
    return results
}

登录后复制

完整示例代码

package main

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

type Result struct {
    successful int
    total      int
    timeouts   int
    errors     int
    duration   time.Duration
}

func makeRequests(url string, messages int, resultChan chan<- *http.Response) {
    for i := 0; i < messages; i++ {
        resp, err := http.Get(url) // 获取错误返回值
        if err != nil {
            resultChan <- nil // 请求失败，发送nil响应
        } else {
            resultChan <- resp // 请求成功，发送实际响应
        }
    }
}

func deployRequests(url string, threads int, messages int) *Result {
    results := new(Result)
    resultChan := make(chan *http.Response)
    start := time.Now()
    defer func() {
        results.duration = time.Since(start)
        fmt.Printf("总耗时: %s\n", results.duration)
    }()

    for i := 0; i < threads; i++ {
        // 确保每个goroutine发送的请求总数覆盖messages
        // 这里 (messages/threads)+1 是为了处理 messages 不能被 threads 整除的情况
        go makeRequests(url, (messages/threads)+1, resultChan)
    }

    // 循环接收结果，直到总数达到预期
    // 注意：这里需要确保所有goroutine都完成，或者明确关闭channel
    // 否则如果messages不能被threads整除，可能导致多余的请求被发送，
    // 或者如果所有goroutine都完成且channel未关闭，range循环会死锁。
    // 更健壮的做法是使用sync.WaitGroup和关闭channel。
    expectedTotal := messages // 期望的总请求数
    receivedCount := 0

    for response := range resultChan {
        receivedCount++
        if response == nil { // 检查是否为nil响应，表示请求失败
            results.errors += 1
        } else if response.StatusCode != 200 {
            results.errors += 1
        } else {
            results.successful += 1
        }
        results.total = receivedCount // 更新总数

        if receivedCount == expectedTotal {
            // 在实际生产代码中，这里可能需要考虑关闭所有goroutine或使用其他同步机制
            // 否则如果还有goroutine在尝试发送，会发生panic
            // 但对于当前问题场景，这个逻辑足以解决死锁
            return results
        }
    }
    return results
}

func main() {
    // 调整请求总数，确保与goroutine发送的总数匹配
    // 实际发送的请求总数可能会略大于messages，因为 (messages/threads)+1
    // 这里为了简化，我们假设 messages 是 threads 的倍数或者接近
    // 或者更精确地计算实际发送的总数
    totalMessages := 1000
    threads := 10
    results := deployRequests("http://www.google.com", threads, totalMessages)
    fmt.Printf("总请求数: %d\n", results.total)
    fmt.Printf("成功请求数: %d\n", results.successful)
    fmt.Printf("错误请求数: %d\n", results.errors)
    fmt.Printf("超时请求数: %d\n", results.timeouts)
}

登录后复制

进一步优化与最佳实践

尽管上述修复解决了死锁问题，但为了构建更健壮、更高效的并发HTTP客户端，还有一些最佳实践值得采纳：

使用 sync.WaitGroup 确保所有Goroutine完成： sync.WaitGroup是Go语言中用于等待一组Goroutine完成的机制。通过它，可以确保所有makeRequests Goroutine都执行完毕后，再关闭resultChan，这样deployRequests中的for range循环就能优雅地退出，而不会因为提前返回或通道未关闭而死锁。

import "sync"
// ...
func deployRequests(url string, threads int, messages int) *Result {
    // ...
    var wg sync.WaitGroup
    // 实际发送的请求总数可能略大于 messages
    actualMessagesSent := 0
    for i := 0; i < threads; i++ {
        requestsPerGoroutine := (messages/threads) + 1
        actualMessagesSent += requestsPerGoroutine
        wg.Add(1)
        go func() {
            defer wg.Done()
            makeRequests(url, requestsPerGoroutine, resultChan)
        }()
    }

    // 启动一个Goroutine来等待所有工作Goroutine完成并关闭通道
    go func() {
        wg.Wait()
        close(resultChan) // 所有发送者都完成，可以安全关闭通道
    }()

    // ...
    // 循环接收结果，直到通道关闭
    for response := range resultChan {
        // ... 统计逻辑 ...
        results.total++ // 每次收到消息就增加总数
    }
    // 当channel关闭且所有值都被读取后，for range循环会自动退出
    return results
}

登录后复制

设置HTTP请求超时：原始代码没有设置HTTP请求超时。在实际应用中，网络请求可能长时间无响应。为http.Client配置超时时间是至关重要的。

import "net/http"
// ...
var httpClient = &http.Client{
    Timeout: 10 * time.Second, // 设置请求超时
}

func makeRequests(url string, messages int, resultChan chan<- *http.Response) {
    for i := 0; i < messages; i++ {
        resp, err := httpClient.Get(url) // 使用配置了超时的客户端
        // ... 错误处理 ...
    }
}

登录后复制

考虑使用缓冲通道：如果发送方和接收方的处理速度不匹配，或者希望减少Goroutine阻塞，可以考虑使用缓冲通道（make(chan *http.Response, bufferSize)）。缓冲通道允许在发送方和接收方之间存在一定数量的未处理消息，从而提高并发效率。然而，缓冲通道并不能解决本例中的计数失衡导致的死锁问题，它主要用于性能优化。
更精细的错误类型区分： http.Get返回的错误err可能包含多种信息（例如网络错误、DNS解析失败、超时等）。通过errors.As或类型断言可以区分不同类型的错误，从而在统计中更准确地分类，例如区分网络错误和自定义的超时错误。