channel vs mutex

cokeboL

見過一些 gopher， 可能是見識太少了吧，見到golang的cahnnel立刻就叫爺爺了，妄想著一切都用
actor模型，用channel來搞，真懷疑是不是很少有人懂得什么是獨立思考嗎？

chan的好處是帶緩沖，多個chan可以用select搞起來隨便哪個有事都可以搞，缺點比如多個寫入方的
關(guān)閉、相比mutex性能差些，放到chan里的東西如果執(zhí)行完需要放入者再處理結(jié)果，那么就要回調(diào)的
方式了，這會使代碼變得更復(fù)雜

我見過有人寫的獲取某個模塊統(tǒng)計信息的接口，用chan去接受獲取信息的請求，然后計算出信息然后
回調(diào)給獲取信息者，本來就是獲取者直接調(diào)用獲取接口，一步搞定，現(xiàn)在變成了三步，“你似不似傻”。

該用的時候自然要用，但沒必要非要生啦櫻桃去用chan

存在交互就避免不了鎖，chan的內(nèi)部實現(xiàn)也是有鎖，如果chan帶來的好處比解決的問題多，那么請使
用mutex

cokeboL

人們都去哪了啊

lxyscls

回復(fù) 1# cokeboL

我見過有人寫的獲取某個模塊統(tǒng)計信息的接口，用chan去接受獲取信息的請求，然后計算出信息然后
回調(diào)給獲取信息者，本來就是獲取者直接調(diào)用獲取接口，一步搞定，現(xiàn)在變成了三步，“你似不似傻”。

萬一這個獲取過程很長怎么辦？

cokeboL

回復(fù) 3# lxyscls

如果真的需要回調(diào)的場景，可以用chan，我不是說不用，只是有些人什么場景都想用chan
另外，因為多個執(zhí)行流，如果獲取之后才能進(jìn)行下一步，那多個執(zhí)行流獲取，不管是mutex還是
chan，都會排隊；如果獲取之后的操作不是下一步操作必須，那當(dāng)然可以放到異步去做

golang的好處是多個并行流，每個流內(nèi)部可以寫串行的代碼，那些一味鼓吹用chan并且沒有分清
楚場景的人，就是浪費了golang可以寫串行代碼的優(yōu)勢反而把代碼搞復(fù)雜了。。。。

lxyscls

channel不是actor模型，是csp

cokeboL

回復(fù) 5# lxyscls

erlang還有akka哪些框架是actor，chan本身是csp但是chan可以容易地封裝成actor所以很多actor黨想用chan封裝成actor來搞一切邏輯。。

cokeboL

回復(fù) 5# lxyscls

我之前一同事，好多基本的函數(shù)調(diào)用寫成這種：
func A() {
  ch = make(chan T, 1)
  B(ch)
  ret = <-ch
}

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


然后大家好累。。

lxyscls

回復(fù) 7# cokeboL

他也真是閑得蛋疼
萬一 func B的gorutine剛好沒分配到CPU，那不是慢死...

cokeboL

回復(fù) 8# lxyscls

萬幸的是,這哥已經(jīng)離職了,他的代碼讓人全重寫了,祝他好運

lxyscls

channel和mutex其實屌毛關(guān)系都沒有

當(dāng)然，因為某些情況下面可以通過channel把任務(wù)都發(fā)到同一個goroutine上面去，導(dǎo)致了原來的mutex不需要了