使用golang的channel的坑

很多时候我们经过使用有缓冲channel作为通信控制的功能，以至有一些误解和坑出现。

执行下面代码。

<code>package</code> <code>mainimport (    </code><code>"time"</code>

<code>    </code><code>"math/rand"</code><code>)func main(){</code>

<code>    </code><code>cache:=make(chan </code><code>int</code><code>,</code><code>4</code><code>)    go func() {        </code><code>for</code> <code>i:=</code><code>0</code><code>;i&lt; </code><code>10</code><code>;i++ {</code>

<code>            </code><code>cache&lt;-i</code>

<code>        </code><code>}</code>

<code>    </code><code>}()    go getCache(cache)    go getCache(cache)    go getCache(cache)</code>

<code>    </code><code>time.Sleep(</code><code>3</code><code>*time.Second)</code>

<code>}func getCache(cache &lt;-chan </code><code>int</code><code>)  {    </code><code>for</code>  <code>{        select {        </code><code>case</code> <code>i:=&lt;-cache:            println(i)</code>

<code>            </code><code>time.Sleep(time.Duration(rand.Int31n(</code><code>100</code><code>))*time.Millisecond)</code>

<code>    </code><code>}</code>

<code>}</code>

多执行几次看看结果，并不是每一次都是可以顺序输出的，有缓存channel是乱序的。因为这里让一些同学误解了，我在此多解释一下。

针对通道的发送和接收操作都是可能造成相关的goroutine阻塞。试想一下，有多个goroutine向同一个channel发送数据而被阻塞，如果还channel有多余的缓存空间时候，最早被阻塞的goroutine会最先被唤醒。也就是说，这里的唤醒顺序与发送操作的开始顺序是一致的，对接收操作而言亦为如此。无论是发送还是接收操作，运行时系统每次只会唤醒一个goroutine。 而这里的乱序是指，如果像使用channel缓存中多个goroutine实现顺序是正确的，因为每一个goroutine抢到处理器的时间点不一致，所以不能保证顺序。

如下代码。

<code>package</code> <code>mainimport (  </code><code>"fmt"</code>

<code>    </code><code>"sync"</code>

<code>    </code><code>"time"</code><code>)var wg = sync.WaitGroup{}func main() {</code>

<code>    </code><code>wg.Add(</code><code>2</code><code>)</code>

<code>    </code><code>bf := make(chan string, </code><code>64</code><code>) go insert(bf)  go get(bf)</code>

<code>    </code><code>wg.Wait()</code>

<code>}func insert(bf chan string) {</code>

<code>    </code><code>str := </code><code>"CockroachDB 的技术选型比较激进，比如依赖了 HLC 来做事务的时间戳。但是在 Spanner 的事务模型的 Commit Wait 阶段等待时间的选择，CockroachDB 并没有办法做到 10ms 内的延迟；CockroachDB 的 Commit Wait 需要用户自己指定，但是谁能拍胸脯说 NTP 的时钟误差在多少毫秒内？我个人认为在处理跨洲际机房时钟同步的问题上，基本只有硬件时钟一种办法。HLC 是没办法解决的。另外 Cockroach 采用了 gossip 来同步节点信息，当集群变得比较大的时候，gossip 心跳会是一个非常大的开销。当然 CockroachDB 的这些技术选择带来的优势就是非常好的易用性，所有逻辑都在一个 binary 中，开箱即用，这个是非常大的优点。"</code>

<code>    </code><code>for</code> <code>i := </code><code>0</code><code>; i &lt; </code><code>10000000</code><code>; i++ {</code>

<code>        </code><code>bf &lt;- fmt.Sprintf(</code><code>"%s%d"</code><code>, str, i)</code>

<code>    </code><code>wg.Done()</code>

<code>}func sprint(s string) {</code>

<code>    </code><code>time.Sleep(</code><code>1000</code> <code>* time.Millisecond)</code>

<code>}func get(bf chan string) { </code><code>for</code> <code>{      go func() {           select {           </code><code>case</code> <code>str := &lt;-bf:</code>

<code>                </code><code>sprint(str)         </code><code>case</code> <code>&lt;-time.After(</code><code>3</code> <code>* time.Second):</code>

<code>                </code><code>wg.Done()</code>

<code>            </code><code>}</code>

<code>        </code><code>}()</code>

很多同学乍一看以为定义了

<code>bf := make(chan string, </code><code>64</code><code>)</code>

就是说该程序的并发度控制在了64，执行就会发现内存一直在增长。 因为get()函数中启动的goroutine会越来越多，因为get()每读取一个数据，insert()就会往channel插入一条数据，此时并发度就不是64了。 需要修改为：

<code>    </code><code>bf := make(chan string, </code><code>64</code><code>) go insert(bf)  </code><code>//go get(bf)</code>

<code>    </code><code>for</code> <code>i:=</code><code>0</code><code>;i&lt;</code><code>64</code><code>;i++ {        go get1(bf)</code>

<code>}func get1(bf chan string)  {    </code><code>for</code> <code>{        select {        </code><code>case</code> <code>str := &lt;-bf:</code>

<code>            </code><code>sprint(str)        </code><code>case</code> <code>&lt;-time.After(</code><code>3</code> <code>* time.Second):</code>

<code>            </code><code>wg.Done()</code>

版权声明：原创作品，如需转载，请注明出处。否则将追究法律责任

本文转自 梦朝思夕 51CTO博客，原文链接:http://blog.51cto.com/qiangmzsx/1966399