Golang Go语言小白写的并发判断函数,请问有没有什么可以优化的地方

发布于 1周前 作者 wuwangju 来自 Go语言


Golang Go语言小白写的并发判断函数,请问有没有什么可以优化的地方

19 回复

为什么不用 errgroup

更多关于Golang Go语言小白写的并发判断函数,请问有没有什么可以优化的地方的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


谢谢解答,我试试

看了一下 errGroup 的用法,虽然也可以代替 waitgroup ,但是好像和 errGroup 的定义即有错误就退出的应用场景有点不太相符吧?

你这样给 result 赋值可能会因为 data race 而 panic 吧

既然都用了 wait group 了为什么 MultiJudge 还要额外用 resultChan 来控制,为什么不直接把 wg.Wait 移到外面来,删掉 result chan ?

或者直接用 result chan 来传递各个 goroutine 的结果,还能避免并发读写的问题。

这里 result data race 会 panic ?我以为是未定义呢。

result 确实会 panic

这两个函数没一个字的注释,我敢说,你自己都没想明白到底是要做什么。

最大的问题是写的太啰嗦。实际项目上不会这么写。

前面大佬说了 result 共享内存了都, 玩的什么🐍皮

这个其实做的是 if(judge1(value) || judge2(value) || judge3(value)) 这样的判断,如果有一个返回真其他就不继续等待结果了,所以我把 wg.Wait()放到协程里去了

的确是未定义,开了 -race 才会报错

#9 你的 gorountine 里面就没必要写 resultChan <- ,这些 router 都已经运行完了 judgeFunc(value),为什么还要阻塞呢。

https://gist.github.com/Trim21/157f85d710dae45e29d7c10504a4c93d

atomic 没给 bool 类型,就直接用 int32 了

多谢大佬的指导

因为我想有一个 judgefunc 为这真就马上返回结果,不等待其他协程运行结束,所以把 wg.wait 放到协程里,如果都不为真,wg.wait 语句结束后会往 resultchan 里传值,外面语句接收到信号后才返回结果 false

搞个 judgefuncs 次长度的 resultChan ,就在外面读 judgefuncs 次 resultChan , 有 true 就返回 true ,一轮下来都没就 false 。

https://gist.github.com/murDDock/a89734f2378bf433d18c9f6a814e7918 我稍微修改了一下 有点啰嗦 我也不太行 一起学习

https://gist.github.com/mingkwind/fdbf7d076a6677d3d89bdc06c49053bd
采取 4P/14P/15P 的意见,改完差不多是这样

说句难听的,充满了脱裤子放屁。。。

您好!很高兴看到您尝试用Go语言编写并发判断函数。Go语言以其强大的并发处理能力而闻名,不过对于初学者来说,确实有一些常见的陷阱和可以优化的地方。以下是一些建议:

  1. 使用sync包:如果您在多个goroutine之间共享数据,建议使用sync.Mutexsync.RWMutex来保护这些数据,避免数据竞争。此外,对于简单的计数器或标志位,可以使用sync.WaitGroupsync.Atomic包提供的原子操作。

  2. 避免死锁:确保每次加锁后都有对应的解锁操作,特别是在复杂的逻辑分支中。可以使用defer关键字来确保在函数返回前解锁。

  3. 合理设置goroutine数量:过多的goroutine可能导致上下文切换频繁,影响性能。可以使用带缓冲区的channel来控制goroutine的并发度。

  4. 错误处理:确保您的并发函数中有适当的错误处理逻辑,避免panic导致程序崩溃。

  5. 代码可读性:尽量保持代码简洁明了,避免过于复杂的逻辑嵌套。可以使用Go语言的特性如匿名函数、闭包等来简化代码结构。

  6. 测试:编写单元测试来验证并发函数的行为,确保其在不同并发场景下的正确性。

希望这些建议对您有所帮助!如果您有具体的代码片段,我可以提供更具体的优化建议。继续加油,Go语言的并发编程非常强大,值得深入学习。

回到顶部