在使用 channel 进行 goroutine 之间的通信时，有时候场面会变得十分复杂，以至于写出难以觉察、难以定位的偶现 bug，而且上线的时候往往跑得好好的，直到某一天深夜收到服务挂了、OOM 了之类的告警……,本文来梳理一下使用 channel 中常见的三大坑：panic、死锁、内存泄漏，做到防患于未然。,go 语言新手在编译时很容易碰到这个死锁的问题：,这个就是喜闻乐见的「死锁」了…… 在操作系统中，我们学过，「死锁」就是两个线程互相等待，耗在那里，最后程序不得不终止。go 语言中的「死锁」也是类似的，两个 goroutine 互相等待，导致程序耗在那里，无法继续跑下去。看了很多死锁的案例后，channel 导致的死锁可以归纳为以下几类案例（先讨论 unbuffered channel 的情况）：,channel 的生产者和消费者必须成对出现，如果缺乏一个，就会造成死锁，例如：,或是：,除了需要成对出现，还需要出现在不同的 goroutine 中，例如：,对于 buffered channel 则是：,buffered channel 会将收到的元素先存在 hchan 结构体的 ringbuffer 中，继而才会发生阻塞。而当发生阻塞时，如果阻塞了主 goroutine ，则也会出现死锁。,所以实际使用中，推荐尽量使用 buffered channel ，使用起来会更安全，在下文的「内存泄漏」相关内容也会提及。,内存泄漏一般都是通过 OOM(Out of Memory) 告警或者发布过程中对内存的观察发现的，服务内存往往都是缓慢上升，直到被系统 OOM 掉清空内存再周而复始。,在 go 语言中，错误地使用 channel 会导致 goroutine 泄漏，进而导致内存泄漏。,不会修 bug，我还不会写 bug 吗？让 goroutine 泄漏的核心就是：,生产者/消费者 所在的 goroutine 已经退出，而其对应的 消费者/生产者 所在的 goroutine 会永远阻塞住，直到进程退出。,我们一般会用 channel 来做一些超时控制，例如下面这个例子：,这里我们用 goroutine g1 来模拟 io 操作，主 goroutine g2 来模拟客户端的处理逻辑。,如果这是在 server 代码中，这个请求处理完后，g1 就会挂起、发生泄漏了，就等着 OOM 吧 =。=。,如果生产者不继续生产，消费者所在的 goroutine 也会阻塞住，不会退出，例如：,这种情况下，只需要增加 close(ch) 的操作即可，for-range 操作在收到 close 的信号后会退出、goroutine 不再阻塞，能够被回收。,预防 goroutine 泄漏的核心就是：,具体到执行层面，包括：,panic 就更刺激了，一般是测试的时候没发现，上线之后偶现，程序挂掉，服务出现一个超时毛刺后触发告警。channel 导致的 panic 一般是以下几个原因：,先举一个简单的栗子：,在实际开发过程中，处理多个 goroutine 之间协作时，可能存在一个 goroutine 已经 close 掉 channel 了，另外一个不知道，也去 close 一下，就会 panic 掉，例如：,万恶之源就是在 go 语言里，你是无法知道一个 channel 是否已经被 close 掉的，所以在尝试做 close 操作的时候，就应该做好会 panic 的准备……,同上，在尝试往 channel 里发送数据时，就应该考虑。,这个 channel 已经关了吗？,这个 channel 什么时候、在哪个 goroutine 里关呢？,谁来关呢？还是干脆不关？,刚遇到上面说的 panic 问题时，我也试过去找一个内置的 closed 函数来检查关闭状态，结果发现，并没有这样一个函数……,那么，如果有这样的函数，真能彻底解决 panic 的问题么？答案是不能。因为 channel 是在一个并发的环境下去做收发操作，就算当前执行 closed(ch) 得到的结果是 false，还是不能直接去关，例如如下 yy 出来的代码：,遵循 less is more 的原则，这个 closed 函数是要不得了,结论：除非必须关闭 chan，否则不要主动关闭。关闭 chan 最优雅的方式，就是不要关闭 chan~。,当一个 chan 没有 sender 和 receiver 时，即不再被使用时，GC 会在一段时间后标记、清理掉这个 chan。那么什么时候必须关闭 chan 呢？比较常见的是将 close 作为一种通知机制，尤其是生产者与消费者之间是 1:M 的关系时，通过 close 告诉下游：我收工了，你们别读了。,chan 关闭的原则:,只要我们遵循这两条原则，就能避免两种 panic 的场景，即：向 closed chan 发送数据，或者是 close 一个 closed chan。,按照生产者和消费者的关系可以拆解成以下几类情况：,本文转载自微信公众号「 翔叔架构笔记」，可以通过以下二维码关注。转载本文请联系翔叔架构笔记公众号。,
© 版权声明
文章版权归作者所有，未经允许请勿转载。
