golang 中的 time 包的 Ticker

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

真實的應用情境是：在測試收包的順序的時候，加了個 tick 就發現丟包了

那麼來看一個應用例子：

package mainimport (    "fmt"    "runtime"    "time")func init() {    runtime.GOMAXPROCS(runtime.NumCPU())}func main() {    ch := make(chan int, 1024)    go func(ch chan int) {        for {            val := <-ch            fmt.Printf("val:%d\n", val)        }    }(ch)    tick := time.NewTicker(1 * time.Second)    for i := 0; i < 20; i++ {        select {        case ch <- i:        case <-tick.C:            fmt.Printf("%d: case <-tick.C\n", i)        }            time.Sleep(200 * time.Millisecond)    }    close(ch)    tick.Stop()}

輸出結果如下：

val:0val:1val:2val:3val:4val:56: case <-tick.Cval:7val:8val:910: case <-tick.Cval:11val:12val:13val:1415: case <-tick.Cval:16val:17val:18val:19

問題出在這個select裡面：

select {    case ch <- i:    case <-tick.C:    　　fmt.Printf("%d: case <-tick.C\n", i)}

　　[tick.C 介紹說明] 當兩個 case 條件都滿足的時候，運行時系統會通過一個偽隨機的演算法決定哪個case將會被執行。所以當 tick.C 條件滿足的那個迴圈，有某種機率造成 ch<-i 沒有發送(雖然通道兩端沒有阻塞，滿足發送條件)

　解決方案1：一旦 tick.C 隨機的 case 被隨機到，就多執行一次 ch<-i (不體面，如果有多個case就不通用了)

select {    case ch <- i:    case <-tick.C:        fmt.Printf("%d: case <-tick.C\n", i)        ch <- i}

   解決方案2：將tick.C的case單獨放到一個select裡面，並加入一個default（保證不阻塞）

select {    case ch <- i:}select {    case <-tick.C:        fmt.Printf("%d: case <-tick.C\n", i)    default:}

兩種解決方案的輸出都是希望的結果：

val:0val:1val:2val:3val:45: case <-tick.Cval:5val:6val:7val:8val:910: case <-tick.Cval:10val:11val:12val:13val:1415: case <-tick.Cval:15val:16val:17val:18val:19