Go语言协程处理数据有哪些问题
前言
一、Goroutine
二、sync.WaitGroup
三、数据排序
四、限制协程数
五、协程Panic处理
总结
前言我们在开发后台项目常常会遇到一个情况，功能模块列表数据导出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被接受，不会导致程序奔溃。
总结协程在处理数据数据通过使用更多资源提升效率协程过多会暂用其他服务资源，我们使用协程过多时需要考虑限制协程中panic需要处理，不然会导致程序崩溃
到此这篇关于Go语言协程处理数据有哪些问题的文章就介绍到这了,更多相关Go协程处理数据内容请搜索软件开发网以前的文章或继续浏览下面的相关文章希望大家以后多多支持软件开发网！
