怎样理解“Do not communicate by sharing memory; instead, share memory by communicating.”

这是一种开发经验之谈吧,可以认为是一种设计模式。communicate by sharing memory需要考虑加锁避免race condition,加锁又会提高开发及调试难度。而 share memory by communicating则可以将对共享资源(memory)的访问串行化,于是就不用考虑race condition了。后者有点像UI编程的消息驱动模型。

■网友
其实这两种模式在Go语言都有很好的支持,所以我觉得这句话可以理解为宣传channel之优雅的一句口号而已,实际使用时还是应该具体问题具体分析。比如用一个计数器统计PageView,符合直觉的方式就是用Mutex把计数器锁一下,如果单开一个goroutine从某个channel中收消息做累加就有些奇怪了。再如做用户互发的短消息,用channel来做消息发送更直观,若是先把消息放到对方的邮箱在用信号量什么的去通知就显得太蹩脚了。
■网友
在golang中,goroutine是有三个主要的陷阱:
goroutine leaks data raceincomplete work 对于1和3的情况:Never start a goroutine without knowing how it will stop.
对于2:Don\u0026#39;t communicate by sharing memory, share memory by communicating.
遵循以上能尽量避免以上三个问题的发生

再直白一点就是:
每当使用go启动一个goroutine时一定要注意它是否能正常结束多个goroutine同时操作同一个变量(communicate by sharing memory),会有数据竞争的问题,尽量不要用这种方式;而推荐用传递共享方式,一个goroutine处理完了以后传递给另一个goroutine继续处理(share memory by communicating) 【怎样理解“Do not communicate by sharing memory; instead, share memory by communicating.”】 以上是个人理解,仅供参考

■网友
就像go官方的搬运工演示中每一个go吉祥物工作过程中并不共享自己的数据各自做各自的,除非有交换动作才会共享数据给交接方。


    推荐阅读