今天在修正昨天的文章《orDone的两种实现》中的压测代码时,无意发现其中的二分递归版的代码是有问题的。
主要是goroutine
泄露的问题,下边简单说明下,也参考自文章记一次学习 orDone 模式爬坑经历
goroutine泄露
1 2 3 4 5 6 7 8 9 10 11 12 13 14
| orDone := make(chan interface{}) go func() { defer close(orDone) switch len(channels) { case 2: ... default: m := len(channels) / 2 select { case <-or(channels[:m]...): case <-or(channels[m:]...): } } }()
|
原代码递归时,没有将结束通道orDone
合并,在orDone
关闭后,没法通知递归中的goroutine
退出,有goroutine
泄露的可能
可修改为
1 2 3 4
| select { case <-OrWithIssue(append(channels[:m:m], orDone)...): case <-OrWithIssue(append(channels[m:], orDone)...): }
|
无限递归
以上代码时,还有个问题是在参数为三个chan
时会无限递归,(文末参考文章里有通过打印协程数来测试这个问题的代码,感兴趣可以去看下)
递归树如下:
1 2 3 4 5 6
| f(3) f(2) f(3) f(2) f(3) f(2) f(3) ...
|
所以需要对3这种case
区分处理
最终代码如下:
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
| func OrRecur(channels ...<-chan interface{}) <-chan interface{} { switch len(channels) { case 0: return nil case 1: return channels[0] }
orDone := make(chan interface{}) go func() { defer close(orDone)
switch len(channels) { case 2: select { case <-channels[0]: case <-channels[1]: } case 3: select { case <-channels[0]: case <-channels[1]: case <-channels[2]: } default: m := len(channels) / 2 select { case <-OrRecur(append(channels[:m:m], orDone)...): case <-OrRecur(append(channels[m:], orDone)...): } } }()
return orDone }
|
最后,再补充下修正后压测结果,二分递归比反射性能更好些
感兴趣可以自己跑下压测代码
虽然是常见的orDone模式,但还是有不少可以探究的地方,想要用好chan还是需要足够仔细啊。
如有疑问,请文末留言交流或邮件:newbvirgil@gmail.com
本文链接 : https://newbmiao.github.io/2021/08/22/recursive-ordone-issue.html