Golang Go语言小白写的并发判断函数,请问有没有什么可以优化的地方
为什么不用 errgroup
更多关于Golang Go语言小白写的并发判断函数,请问有没有什么可以优化的地方的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
谢谢解答,我试试
看了一下 errGroup 的用法,虽然也可以代替 waitgroup ,但是好像和 errGroup 的定义即有错误就退出的应用场景有点不太相符吧?
既然都用了 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 的意见,改完差不多是这样
说句难听的,充满了脱裤子放屁。。。
errgroup +1
您好!很高兴看到您尝试用Go语言编写并发判断函数。Go语言以其强大的并发处理能力而闻名,不过对于初学者来说,确实有一些常见的陷阱和可以优化的地方。以下是一些建议:
-
使用sync包:如果您在多个goroutine之间共享数据,建议使用
sync.Mutex
或sync.RWMutex
来保护这些数据,避免数据竞争。此外,对于简单的计数器或标志位,可以使用sync.WaitGroup
或sync.Atomic
包提供的原子操作。 -
避免死锁:确保每次加锁后都有对应的解锁操作,特别是在复杂的逻辑分支中。可以使用
defer
关键字来确保在函数返回前解锁。 -
合理设置goroutine数量:过多的goroutine可能导致上下文切换频繁,影响性能。可以使用带缓冲区的channel来控制goroutine的并发度。
-
错误处理:确保您的并发函数中有适当的错误处理逻辑,避免panic导致程序崩溃。
-
代码可读性:尽量保持代码简洁明了,避免过于复杂的逻辑嵌套。可以使用Go语言的特性如匿名函数、闭包等来简化代码结构。
-
测试:编写单元测试来验证并发函数的行为,确保其在不同并发场景下的正确性。
希望这些建议对您有所帮助!如果您有具体的代码片段,我可以提供更具体的优化建议。继续加油,Go语言的并发编程非常强大,值得深入学习。