如果我正确使用频道,我是否需要使用互斥锁？

如果我正确使用频道,我是否需要使用互斥锁来防止并发访问？

1> icza..：

---

如果正确使用通道,则不需要互斥锁.在某些情况下,使用互斥锁的解决方案可能更简单.

只需确保在多个goroutine尝试访问通道变量之前,正确初始化了保存通道值的变量.完成此操作后,访问通道(例如,向其发送值或从中接收值)是安全的.

带参考文献的支持文件(我强调的重点):

规格:渠道类型:

单个信道,可以使用在发送的语句,接收操作,并调用内置的功能cap和通过任何数量的够程无需进一步同步.频道充当先进先出队列.例如,如果一个goroutine在一个通道上发送值而另一个goroutine接收它们,则按发送的顺序接收这些值.len

有效围棋:并发:通过沟通分享

由于实现对共享变量的正确访问所需的微妙之处,许多环境中的并发编程变得困难.Go鼓励采用一种不同的方法,在这种方法中,共享值在通道上传递,实际上,不会由单独的执行线程主动共享.在任何给定时间,只有一个goroutine可以访问该值.根据设计,数据竞争不会发生.为了鼓励这种思维方式,我们将其简化为一个口号:

不要通过共享内存进行通信; 相反,通过沟通分享记忆.

这种方法可以采取太多措施.例如,可以通过在整数变量周围放置互斥量来最好地完成引用计数.但作为一种高级方法,使用通道来控制访问可以更容易地编写清晰,正确的程序.

本文也非常有用:Go Memory Model

还引用了包文档sync:

包同步提供基本同步原语,例如互斥锁.除了Once和WaitGroup类型之外,大多数类型都适用于低级库例程.通过通道和通信可以更好地完成更高级别的同步.

---

虽然这是一个很好的一般准则,但我认为我们真的需要强调"这种方法可以采取太长的措施." 警告.我已经看到了很多非常复杂的代码源于此,有一堆反应器循环和消息传递,其中一个简单的互斥量就足够了.我是如何想到这个问题的:如果你试图围绕单个*逻辑资源提供"互斥",那么你可能需要一个互斥量.如果您正在尝试协调goroutine并提供同步点,那么您需要通道.(介于两者之间的一切都来自经验)