Concurrency on DK Blog

Errgroup 的应用场景

Sun, 29 Jun 2025 17:13:11 +0800

Go 并发任务管理：errgroup 两种核心模式实战指南

一、背景与现状描述

在 Go 语言并发编程中，我们经常需要处理「一组并行任务」，并面临两个核心问题：

如何等待所有任务完成？
如何处理任务执行中出现的错误？

现有方案的局限

sync.WaitGroup：仅能等待任务完成，无法传递错误，需额外通过 channel 或共享变量收集错误，代码繁琐。
手动管理 goroutine + channel：可实现错误传递，但需手动处理 goroutine 生命周期、错误聚合、退出信号等，易出现漏处理（如 goroutine 泄漏）。
errgroup 的价值：作为官方扩展库（golang.org/x/sync/errgroup）提供的工具，它在 WaitGroup 基础上封装了错误传递和上下文管理能力，大幅简化并发任务的错误处理逻辑。

二、errgroup 核心能力概述

errgroup 主要解决两类场景的问题：

快速失败模式：任一任务出错时，立即终止所有任务并返回错误（适合任务强依赖场景）。
全量执行模式：所有任务无论成功与否都执行完毕，最终汇总所有错误（适合任务独立场景, 例如检测节点健康状态）。

其核心结构体为 errgroup.Group，提供两个关键方法：

Go(f func() error)：提交一个并发任务（函数返回错误）。
Wait() error：等待所有任务完成，返回第一个非空错误（或 nil）。

三、场景一：快速失败模式（使用 `errgroup.WithContext`）

3.1 场景定义

当一组任务中，任一任务失败会导致其他任务失去执行意义时（如分布式事务、多步骤依赖的接口调用），需要“一错全停”，避免资源浪费。

3.2 实现原理

通过 errgroup.WithContext(context.Background()) 创建带上下文的 Group：

当任一任务返回错误时，Group 会自动取消关联的上下文（ctx）。
其他任务可通过监听 ctx.Done() 提前感知取消信号，终止执行。

3.3 实战案例：分布式配置加载

3.3.1 需求

从 3 个依赖的配置中心（A、B、C）并发加载配置，任一加载失败则整体失败，避免使用不完整的配置。

3.3.2 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84


package main

import (
	"context"
	"errors"
	"fmt"
	"log"
	"sync"
	"time"

	"golang.org/x/sync/errgroup"
)

// Config 配置数据结构
type Config struct {
	Source string // 配置来源（A/B/C）
	Data map[string]string
}

// 从配置中心加载数据（模拟可能失败）
func loadConfig(ctx context.Context, source string, delay time.Duration) (Config, error) {
	// 模拟网络请求，同时监听上下文取消
	select {
	case <-ctx.Done():
		return Config{}, fmt.Errorf("配置中心 %s 加载被终止：%w", source, ctx.Err())
	case <-time.After(delay):
		// 模拟随机失败（仅配置中心B有30%概率失败）
		if source == "B" && time.Now().UnixNano()%10 < 3 {
			return Config{}, errors.New("连接超时")
		}
		return Config{
			Source: source,
			Data: map[string]string{"timeout": "30s", "maxConn": "100"},
		}, nil
	}
}

func main() {
	// 1. 创建带上下文的errgroup（快速失败核心）
	g, ctx := errgroup.WithContext(context.Background())

	// 2. 并发安全存储配置结果
	var (
		configs []Config
		mu sync.Mutex
	)

	// 3. 定义任务列表（3个配置中心）
	sources := []struct {
		name string
		delay time.Duration
	}{
		{"A", 100 * time.Millisecond},
		{"B", 150 * time.Millisecond}, // 可能失败的节点
		{"C", 200 * time.Millisecond},
	}

	// 4. 提交任务
	for _, s := range sources {
		source := s // 捕获循环变量，避免闭包陷阱
		g.Go(func() error {
			cfg, err := loadConfig(ctx, source.name, source.delay)
			if err != nil {
				return fmt.Errorf("配置中心 %s 加载失败：%w", source.name, err)
			}
			// 安全添加结果
			mu.Lock()
			configs = append(configs, cfg)
			mu.Unlock()
			return nil
		})
	}

	// 5. 等待所有任务完成并处理结果
	if err := g.Wait(); err != nil {
		log.Fatalf("配置加载失败：%v", err)
	}

	// 6. 所有配置加载成功
	fmt.Println("所有配置加载成功：")
	for _, cfg := range configs {
		fmt.Printf("来源 %s: %+v\n", cfg.Source, cfg.Data)
	}
}

3.3.3 执行结果分析

失败场景：若配置中心 B 失败，ctx 被取消，配置中心 C 会因 <-ctx.Done() 提前终止，g.Wait() 返回 B 的错误。
成功场景：所有配置中心加载完成，汇总结果并输出。

四、场景二：全量执行模式（不使用 `errgroup.WithContext`）

4.1 场景定义

当任务之间相互独立，即使部分任务失败，仍需执行所有任务并汇总所有错误时（如批量数据校验、多节点健康检查），需要“全量执行，集中报错”。

4.2 实现原理

直接创建 errgroup.Group（不关联上下文）：

任务失败不会触发其他任务终止，所有任务都会执行完毕。
通过自定义错误收集器（如封装锁和切片的结构体）收集所有错误。

4.3 实战案例：多节点健康检查

4.3.1 需求

检查 5 个服务节点的健康状态，无论部分节点是否异常，都需等待所有检查完成，最终汇总异常节点信息。

4.3.2 代码实现

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100


package main

import (
	"errors"
	"fmt"
	"sync"
	"time"

	"golang.org/x/sync/errgroup"
)

// 1. 错误收集器：并发安全的错误管理
type ErrorCollector struct {
	mu sync.Mutex
	errs []error
}

func NewErrorCollector() *ErrorCollector {
	return &ErrorCollector{}
}

// 添加错误（忽略空错误）
func (c *ErrorCollector) Add(err error) {
	if err == nil {
		return
	}
	c.mu.Lock()
	defer c.mu.Unlock()
	c.errs = append(c.errs, err)
}

// 获取所有错误（返回副本，避免外部修改）
func (c *ErrorCollector) AllErrors() []error {
	c.mu.Lock()
	defer c.mu.Unlock()
	copied := make([]error, len(c.errs))
	copy(copied, c.errs)
	return copied
}

// 2. 节点健康检查任务
type NodeCheckTask struct {
	NodeName string // 节点名称
	Timeout time.Duration // 检查超时时间
}

// 执行健康检查（模拟可能失败）
func (t *NodeCheckTask) Check() error {
	time.Sleep(t.Timeout) // 模拟检查耗时
	// 模拟随机失败（20%概率）
	if time.Now().UnixNano()%10 < 2 {
		return errors.New("心跳无响应")
	}
	fmt.Printf("节点 %s 健康检查通过\n", t.NodeName)
	return nil
}

func main() {
	// 1. 初始化组件
	errCollector := NewErrorCollector()
	var g errgroup.Group

	// 2. 定义检查任务列表
	nodes := []NodeCheckTask{
		{"node-1", 100 * time.Millisecond},
		{"node-2", 150 * time.Millisecond},
		{"node-3", 200 * time.Millisecond},
		{"node-4", 180 * time.Millisecond},
		{"node-5", 220 * time.Millisecond},
	}

	// 3. 提交所有检查任务
	for _, node := range nodes {
		task := node // 捕获循环变量
		g.Go(func() error {
			if err := task.Check(); err != nil {
				// 包装错误并添加到收集器
				wrappedErr := fmt.Errorf("节点 %s 异常：%w", task.NodeName, err)
				errCollector.Add(wrappedErr)
				return wrappedErr // 不影响其他任务
			}
			return nil
		})
	}

	// 4. 等待所有任务完成（忽略g.Wait()返回的第一个错误）
	_ = g.Wait()

	// 5. 汇总结果
	if len(errCollector.AllErrors()) == 0 {
		fmt.Println("\n所有节点健康检查通过")
		return
	}

	// 输出所有异常
	fmt.Printf("\n共 %d 个节点异常：\n", len(errCollector.AllErrors()))
	for _, err := range errCollector.AllErrors() {
		fmt.Printf("- %v\n", err)
	}
}

4.3.3 执行结果分析

无论多少节点失败，所有 5 个节点的检查都会执行完毕。
最终输出所有异常节点的错误信息，便于运维人员批量处理。

五、两种模式对比与最佳实践

维度	快速失败模式（`WithContext`）	全量执行模式（无 `WithContext`）
核心目标	一错全停，减少无效执行	全量执行，汇总所有错误
上下文依赖	依赖 `errgroup` 生成的 `ctx`	无（或自定义上下文）
错误处理	只返回第一个错误	收集所有错误
适用场景	任务强依赖（如分布式事务）	任务独立（如批量检查）
代码关键差异	使用 `g, ctx := errgroup.WithContext(...)`	直接声明 `var g errgroup.Group`

最佳实践

错误包装：始终使用 fmt.Errorf("%w", err) 包装错误，保留错误链和上下文（如任务名称、来源）。
并发安全：共享资源（如结果切片）必须通过 sync.Mutex 或 channel 保证安全，避免数据竞争。
闭包陷阱：循环提交任务时，需通过 task := t 捕获当前变量副本，防止所有 goroutine 引用同一变量。
上下文监听：快速失败模式中，任务函数需通过 select <-ctx.Done() 监听取消信号，及时退出。

六、总结

errgroup 作为 Go 并发编程的高效工具，通过两种核心模式解决了不同场景下的任务管理问题：

快速失败模式适合任务强依赖场景，通过上下文取消机制实现“一错全停”，减少资源浪费。
全量执行模式适合任务独立场景，通过自定义错误收集器实现“全量执行，集中报错”，满足批量处理需求。

Go channel 使用不当的异常场景：panic 与阻塞

Sat, 14 Jun 2025 14:38:29 +0800

1、panic、阻塞链路场景

1、在 Go 语言中，channel 如果使用不当，可能会导致 panic。以下是操作 channel 时可能引发 panic 的常见场景：

向已关闭的 channel 发送数据
1 2 3 4 5 6 7 8 9

package main import "fmt" func main() { ch := make(chan int) close(ch) ch <- 1 // panic: send on closed channel }
原因：一旦 channel 被关闭，再向其发送数据会触发 panic。

修复：确保只有发送方可以关闭 channel，并通过同步机制（如 sync.WaitGroup）避免并发关闭或发送。可以设计一个明确的关闭策略，例如使用状态标志来指示 channel 是否已关闭。

重复关闭 channel
1 2 3 4 5 6 7

package main func main() { ch := make(chan int) close(ch) close(ch) // panic: close of closed channel }
原因：重复关闭同一个 channel 会直接引发 panic。

修复：确保 channel 只被关闭一次。例如，可以使用 sync.Once 来包裹关闭操作，或者在逻辑设计中添加检查以避免多次关闭的情况。
关闭一个 nil channel
1 2 3 4 5 6

package main func main() { var ch chan int close(ch) // panic: close of nil channel }
原因：nil channel 的关闭操作会触发 panic。

修复：在关闭之前，请始终初始化 channel（例如：ch = make(chan int)）。

以下内容是会造成阻塞的场景

2、在 Go 语言中，channel 如果使用不当，可能会导致阻塞。以下是常见场景：

nil channel 接收数据

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


package main

import "fmt"

func main() {
 var ch chan int
 // 下面的代码将会阻塞：
 // <-ch // 阻塞，但不会 panic
 // v := <-ch // 阻塞，但不会 panic

 // 使用 select 可以避免阻塞
 select {
 case v := <-ch:
 fmt.Println("Received:", v)
 default:
 fmt.Println("No data received, proceeding without blocking")
 }
}

向 nil channel 发送数据

1
2
3
4
5
6
7


package main

func main() {
 var ch chan int
 // 下面的代码将会阻塞：
 // ch <- 1 // 阻塞，但不会 panic
}

select 中的 nil channel 导致阻塞
1 2 3 4 5 6 7 8 9

package main func main() { var ch chan int select { case <-ch: // 阻塞，但不会 panic case ch <- 1: // 阻塞，但不会 panic } }
注意：在 select 中操作 nil channel 会导致对应的 case 被忽略（相当于非阻塞检查）。为了保持代码的健壮性，可以在选择之前确保 channel 初始化。

2、其他注意事项

已关闭的 channel 仍可读取数据：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


package main

import "fmt"

func main() {
 ch := make(chan int, 2)
 ch <- 1
 ch <- 2
 close(ch)

 v1 := <-ch // 1
 v2 := <-ch // 2
 v3 := <-ch // 零值（不 panic）

 fmt.Println(v1, v2, v3) // 输出: 1 2 0
}

3、panic 的根源

多数 channel 相关的 panic 是由于并发操作下的状态不一致（如关闭后发送、重复关闭、关闭 nil channel）。因此，组织代码时要特别注意并发控制和状态管理。

4、项目中的使用实践

由发送方关闭 channel，避免接收方关闭引发竞争。
使用 defer 或同步机制确保 channel 只关闭一次。可通过定义一个关闭函数使用 defer 语句在最后确保及时关闭。
在不确定 channel 是否初始化时，检查是否为 nil。可通过检查 if ch != nil 来防止 nil channel 带来的问题。
通过 select 和 default 避免阻塞操作，确保程序能在无数据时安全处理，而不陷入死锁状态。