channel vs mutex

cokeboL

见过一些 gopher， 可能是见识太少了吧，见到golang的cahnnel立刻就叫爷爷了，妄想着一切都用
actor模型，用channel来搞，真怀疑是不是很少有人懂得什么是独立思考吗？

chan的好处是带缓冲，多个chan可以用select搞起来随便哪个有事都可以搞，缺点比如多个写入方的
关闭、相比mutex性能差些，放到chan里的东西如果执行完需要放入者再处理结果，那么就要回调的
方式了，这会使代码变得更复杂

我见过有人写的获取某个模块统计信息的接口，用chan去接受获取信息的请求，然后计算出信息然后
回调给获取信息者，本来就是获取者直接调用获取接口，一步搞定，现在变成了三步，“你似不似傻”。

该用的时候自然要用，但没必要非要生啦樱桃去用chan

存在交互就避免不了锁，chan的内部实现也是有锁，如果chan带来的好处比解决的问题多，那么请使
用mutex

cokeboL

人们都去哪了啊

lxyscls

回复 1# cokeboL

我见过有人写的获取某个模块统计信息的接口，用chan去接受获取信息的请求，然后计算出信息然后
回调给获取信息者，本来就是获取者直接调用获取接口，一步搞定，现在变成了三步，“你似不似傻”。

万一这个获取过程很长怎么办？

cokeboL

回复 3# lxyscls

如果真的需要回调的场景，可以用chan，我不是说不用，只是有些人什么场景都想用chan
另外，因为多个执行流，如果获取之后才能进行下一步，那多个执行流获取，不管是mutex还是
chan，都会排队；如果获取之后的操作不是下一步操作必须，那当然可以放到异步去做

golang的好处是多个并行流，每个流内部可以写串行的代码，那些一味鼓吹用chan并且没有分清
楚场景的人，就是浪费了golang可以写串行代码的优势反而把代码搞复杂了。。。。

lxyscls

channel不是actor模型，是csp

cokeboL

回复 5# lxyscls

erlang还有akka哪些框架是actor，chan本身是csp但是chan可以容易地封装成actor所以很多actor党想用chan封装成actor来搞一切逻辑。。

cokeboL

回复 5# lxyscls

我之前一同事，好多基本的函数调用写成这种：
func A() {
  ch = make(chan T, 1)
  B(ch)
  ret = <-ch
}

func B(ch chan T) {
  ret = do sth
  ch <- ret
}


然后大家好累。。

lxyscls

回复 7# cokeboL

他也真是闲得蛋疼
万一 func B的gorutine刚好没分配到CPU，那不是慢死...

cokeboL

回复 8# lxyscls

万幸的是,这哥已经离职了,他的代码让人全重写了,祝他好运

lxyscls

channel和mutex其实屌毛关系都没有

当然，因为某些情况下面可以通过channel把任务都发到同一个goroutine上面去，导致了原来的mutex不需要了