channel vs mutex
见过一些 gopher， 可能是见识太少了吧，见到golang的cahnnel立刻就叫爷爷了，妄想着一切都用actor模型，用channel来搞，真怀疑是不是很少有人懂得什么是独立思考吗？
chan的好处是带缓冲，多个chan可以用select搞起来随便哪个有事都可以搞，缺点比如多个写入方的
关闭、相比mutex性能差些，放到chan里的东西如果执行完需要放入者再处理结果，那么就要回调的
方式了，这会使代码变得更复杂
我见过有人写的获取某个模块统计信息的接口，用chan去接受获取信息的请求，然后计算出信息然后
回调给获取信息者，本来就是获取者直接调用获取接口，一步搞定，现在变成了三步，“你似不似傻”。
该用的时候自然要用，但没必要非要生啦樱桃去用chan
存在交互就避免不了锁，chan的内部实现也是有锁，如果chan带来的好处比解决的问题多，那么请使
用mutex
人们都去哪了啊 回复 1# cokeboL
我见过有人写的获取某个模块统计信息的接口，用chan去接受获取信息的请求，然后计算出信息然后
回调给获取信息者，本来就是获取者直接调用获取接口，一步搞定，现在变成了三步，“你似不似傻”。万一这个获取过程很长怎么办？ 回复 3# lxyscls
如果真的需要回调的场景，可以用chan，我不是说不用，只是有些人什么场景都想用chan
另外，因为多个执行流，如果获取之后才能进行下一步，那多个执行流获取，不管是mutex还是
chan，都会排队；如果获取之后的操作不是下一步操作必须，那当然可以放到异步去做
golang的好处是多个并行流，每个流内部可以写串行的代码，那些一味鼓吹用chan并且没有分清
楚场景的人，就是浪费了golang可以写串行代码的优势反而把代码搞复杂了。。。。
channel不是actor模型，是csp{:yct12:} 回复 5# lxyscls
erlang还有akka哪些框架是actor，chan本身是csp但是chan可以容易地封装成actor所以很多actor党想用chan封装成actor来搞一切逻辑。。
回复 5# lxyscls
我之前一同事，好多基本的函数调用写成这种：
func A() {
ch = make(chan T, 1)
B(ch)
ret = <-ch
}
func B(ch chan T) {
ret = do sth
ch <- ret
}
然后大家好累。。
回复 7# cokeboL
他也真是闲得蛋疼
万一 func B的gorutine刚好没分配到CPU，那不是慢死...{:3:}
回复 8# lxyscls
万幸的是,这哥已经离职了,他的代码让人全重写了,祝他好运:dizzy: channel和mutex其实屌毛关系都没有
当然，因为某些情况下面可以通过channel把任务都发到同一个goroutine上面去，导致了原来的mutex不需要了
页:
[1]
2