一、死锁陷阱
关于Go的并发编程，你会遇到哪些陷阱：
- 主协程退出时，所有子协程都一并退出；
- 所有子协程都已经完成工作，但主协程和一些工作协程还存活，这是由于主协程无法获得工作协程的完成状态；
- 多个不同的协程都锁定了受保护的资源而且同时尝试去获得对方资源的时候，即死锁。
以上陷阱的主要缘由是主协程不知道子协程的工作状态和结果
常见解决方案：
- 简约方法：让主协程在一个done 通道上等待，根据接收到的通道信息判断工作是否完成。
- 等待组方法：使用sync.WaitGroup让每个工作协程报告自己的完成状态。
值得注意的是，无论是简约方法，还是等待组方法，都有可能产生死锁：
- 等待组是当所有工作协程都处于锁定状态时（等待接收通道数据）调用sync.WaitGroup.Wait()会产生死锁。
- 假如有若干个协程可以互相通知对方去执行某个函数（向对方发送一个请求），如果这些请求执行的函数中有一个函数向执行它的调用者协程发送一些数据，那就会发生死锁。
二、善用通道
通道为并发运行的协程之间提供了一种无锁通信方式（无人工加解锁），当通道有数据传输时，发送和接收的协程都处于同步状态。
通道使用经验1：默认情况下，通道是双向的，但我们通常在使用通道时，通道变量是作为参数传递的，在通信的另一个协程里我们往往希望它单向使用该通道，要么只发送( ch<- data)，要么只接收( data:= <-ch) ，所以我们往往在声明函数的通道参数时先指定通道方向，以规范协程函数内的通道使用，函数参数声明单向通道会提供额外的编译器检查，开发时我们应该有这种编程习惯。
通道使用经验2：只有在后面要检查通道是否关闭的时候才需要显式的关闭通道。
例如：在一个for ... range.. 循环里，或者select通道多路复用里，或者使用<-操作符来检查是否可以接收等情况，需要显式关闭通道。
通道非常轻量，对系统资源的消耗可忽略不计，简而言之，有检查通道关闭状态需要的情况下，才会去在发送端显式关闭通道，以上经验可应付大部分场景，如有特殊需求可具体情况具体分析。
通道使用经验3：应该由发送端的协程关闭通道，而不是接收端去关闭。
三、并发安全
通常，通道传输值类型（如struct、数组、布尔值、整型、浮点型、甚至字符串）都是安全的，因为它们都是拷贝传输，也就是说并发访问相同的值也没有风险。那么你也可以想到通道传输指针类型和引用类型不能保证数据安全，因为任何得到指针类型或引用类型的变量的协程都可以修改数据，所以当涉及指针和引用时我们必须保证这些变量在任何时候只能被一个协程访问得到，建议指针和引用（甚至可写接口类型）的值访问串行进行。
如何安全的并发访问指针或引用变量：
- 方法一：使用同步锁sync.Mutex，这非常好理解，一个数据只允许一个协程独占使用，当其他协程也需要访问时只能等待；
- 方法二：设定规则，编码自律，即一旦指针或引用被发送后发送方不再访问它，然后接收方访问并在之后释放指针和引用指向的值；
- 方法三：让所有导出的方法不能修改该值，所有可修改值的方法都不引出，这样外部可以引出这些方法进行并发访问，但内部只允许一个协程取访问它的非导出方法。
网友评论