Go语言协程处理数据有哪些问题

前言

我们在开发后台项目常常会遇到一个情况，功能模块列表数据导出Excel功能，但列表中某个字段无法通过Sql联表查询，且一次性查询再匹对也不方便；此时对列表数据循环，再一个个查询结果加入列表，势必需要很长的时间，我们该怎么才能提升下载速度呢？ （这里采用Go开发服务端）

一、Goroutine

当然第一个想到可能是采用协程处理循环里面要查询的数据

type Card struct {
Name    string  `json:"name"`
Balance float64 `json:"balance"`
}
func main() {
// 获取卡列表数据
list := getList()
var data = make([]Card, 0, len(list))
for _, val := range list {
go func(card Card) {
// 查询业务，将值加入该记录中
var balance = getBalance()
data = append(data, Card{
Name:    card.Name,
Balance: balance,
})
}(val)
}
log.Printf("数据：％+v", data)
}
// 获取数据列表
func getList() []Card {
var list = make([]Card, 0)
for i := 0; i < 10000; i++ {
list = append(list, Card{
Name: "卡-" + strconv.Itoa(i+1),
})
}
return list
}
// 获取余额
func getBalance() float64 {
time.Sleep(time.Millisecond * 100)
return float64(rand.Int63n(1000))
}

运行上述代码，结果： "数据：[]"，这是为什么呢？主要是协程处理业务需要时间，循环提前结束，所以才会出现这样的结果，该怎么让所有结果都处理结束才输出结果呢？

二、sync.WaitGroup

此方法就是等待组进行多个任务的同步，等待组可以保证在并发环境中完成指定数量的任务

func main() {
list := getList() // 获取卡列表数据
var data = make([]Card, 0, len(list))
var wg sync.WaitGroup // 声明一个等待组
for _, val := range list {
wg.Add(1) // 每一个任务开始时,将等待组增加1
go func(card Card) {
defer wg.Done() // 使用defer, 表示函数完成时将等待组值减1
// 查询业务,休眠100微妙，将值加入该记录中
var balance = getBalance()
data = append(data, Card{
Name:    card.Name,
Balance: balance,
})
}(val)
}
wg.Wait() // 等待所有任务完成
log.Printf("数据：％+v", data)
}

运行结果会输出所有数据，但细心的我们会发现，这个时候数据的顺序是乱的，这个也符合业务需求，该怎么进一步改良呢？

三、数据排序

上面讲到协程处理之后的额数据是无序的，这里我们知道数据跳数，直接初始化一个len和cap等于len(list)的空间，将之前append到data的数据改成通过下标复制，这样输出的数据就是list的数据顺序。

func main() {
list := getList() // 获取卡列表数据
var data = make([]Card, len(list), len(list))
var wg sync.WaitGroup // 声明一个等待组
for k, val := range list {
wg.Add(1) // 每一个任务开始时,将等待组增加1
go func(k int, card Card) {
defer wg.Done() // 使用defer, 表示函数完成时将等待组值减1
// 查询业务,休眠100微妙，将值加入该记录中
var balance = getBalance()
data[k] = Card{
Name:    card.Name,
Balance: balance,
}
}(k, val)
}
wg.Wait() // 等待所有任务完成
log.Printf("数据：％+v", data)
}

运行上述代码，虽然可以获取到想要的数据排序，但下次下载数据较多，开的协程过多，势必导致资源开销过大，带来一系列问题，那怎么优化限制协程个数呢？

四、限制协程数

大家都知道协程过多，自然消耗过多资源，可能导致其他问题；这里我们借助chan限制协程个数

// 限制100个协程
type pool struct {
queue chan int
wg    *sync.WaitGroup
}
func main() {
list := getList() // 获取卡列表数据
var data = make([]Card, len(list), len(list))
var gl = &pool{queue: make(chan int, 500), wg: &sync.WaitGroup{}} // 显示协程数最大500个
for k, val := range list {
gl.queue <- 1 // 每一个任务开始时, chan输入1个
gl.wg.Add(1)  // 每一个任务开始时,将等待组增加1
go func(k int, card Card) {
defer func() {
<-gl.queue   // 完成时chan取出1个
gl.wg.Done() // 完成时将等待组值减1
}()
// 查询业务,休眠100微妙，将值加入该记录中
var balance = getBalance()
data[k] = Card{
Name:    card.Name,
Balance: balance,
}
}(k, val)
}
gl.wg.Wait() // 等待所有任务完成
log.Printf("数据：％+v", data)
}

通过使用chan，可以自己定义可协程最大数；现在看起来没有什么问题，但如果协程获取数据panic，会导致整个程序崩溃。

五、协程Panic处理

针对协程的panic（），我们需要接收，使用recover处理

func main() {
list := getList() // 获取卡列表数据
var data = make([]Card, len(list), len(list))
var gl = &pool{queue: make(chan int, 500), wg: &sync.WaitGroup{}} // 显示协程数最大500个
for k, val := range list {
gl.queue <- 1 // 每一个任务开始时, chan输入1个
gl.wg.Add(1)  // 每一个任务开始时,将等待组增加1
go func(k int, card Card) {
// 解决协程panic，不至于程序崩溃
defer func() {
recover()
}()
defer func() {
<-gl.queue   // 完成时chan取出1个
gl.wg.Done() // 完成时将等待组值减1
}()
// 查询业务,休眠100微妙，将值加入该记录中
var balance = getBalance()
data[k] = Card{
Name:    card.Name,
Balance: balance,
}
}(k, val)
}
gl.wg.Wait() // 等待所有任务完成
log.Printf("数据：％+v", data)
}
// 获取余额
func getBalance() float64 {
panic("获取余额panic")
time.Sleep(time.Millisecond * 100)
return float64(rand.Int63n(1000))
}

在协程中使用defer recover()；这样协程抛出来的panic被接受，不会导致程序奔溃。

来源：https://blog.csdn.net/qq_34272964/article/details/127025708