信道是一個golang goroutine之間很關鍵的通信媒介。

理解golang的信道很重要，這里記錄平時易忘記的、易混淆的點。

1. 基本使用

剛聲明的信道，零值為nil，無法直接使用，需配合make函數(shù)進行初始化

   ic :=  make(chan int)
   ic  <-22   // 向無緩沖信道寫入數(shù)據(jù)
   v := <-ic  // 從無緩沖信道讀取數(shù)據(jù)

• 無緩沖信道：一手交錢，一手交貨， sender、receiver必須同時做好動作，才能完成發(fā)送->接收；否則，先準備好的一方將會阻塞等待。
• 有緩沖信道 make(chan int,10)：滑軌流水線，因為存在緩沖空間，故并不強制sender、receiver必須同時準備好；當通道空或滿時， 有一方會阻塞。

信道存在三種狀態(tài)：nil， active， closed

針對這三種狀態(tài)，sender、receiver有一些行為，我也不知道如何強行記憶這些行為 ??：

2. 從1個例子看chan的實質

package main
 
import (
    "fmt"
)
 
func SendDataToChannel(ch chan int, value int) {
    fmt.Printf("ch's value：%v, chan's type: %T \n", ch, ch) // %v 顯示struct的值；%T 顯示類型
    ch <- value
}
 
func main() {
    var v int
    ch := make(chan int)     
    fmt.Printf("ch's value：%v, chan's type: %T \n", ch, ch) 
    go SendDataToChannel(ch, 101)         // 通過信道發(fā)送數(shù)據(jù)
    v = <-ch                              //  從信道接受數(shù)據(jù)
    fmt.Println(v)       // 101
}

能正確打印101。

Q1:  剛學習golang的時候，一直給我們灌輸golang函數(shù)是值傳遞，那上例在另外一個協(xié)程內部對形參的操作，為什么會影響外部的實參？

請關注格式化字符的日志輸出：

ch's value：0xc000018180, chan's type: chan int 
ch's value：0xc000018180, chan's type: chan int 
101

A: 上面的日志顯示傳遞的ch是一個指針值0xc000018180，類型是chan int( 這并不是說ch是指向chan int類型的指針)。

chan int本質就是指向hchan結構體的指針。

內置函數(shù)make^[1]創(chuàng)建信道：func makechan(t *chantype, size int) *hchan返回了指向hchan結構體的指針：

type hchan struct {
 qcount   uint           // 隊列中已有的緩存元素的長度
 dataqsiz uint           // 環(huán)形隊列的長度
 buf      unsafe.Pointer // 環(huán)形隊列的地址
 elemsize uint16
 closed   uint32
 elemtype *_type // 元素類型
 sendx    uint   // 待發(fā)送的元素索引
 recvx    uint   // 待接受元素索引
 recvq    waitq  // 阻塞等待的goroutine
 sendq    waitq  // 阻塞等待的gotoutine

 // lock protects all fields in hchan, as well as several
 // fields in sudogs blocked on this channel.
 //
 // Do not change another G's status while holding this lock
 // (in particular, do not ready a G), as this can deadlock
 // with stack shrinking.
 lock mutex
}

Q2：緩沖信道內部為什么要使用環(huán)形隊列？

A：golang是使用數(shù)組來實現(xiàn)信道隊列，在不移動元素的情況下， 隊列會出現(xiàn)“假滿”的情況，

在做成環(huán)形隊列的情況下， 所有的入隊出隊操作依舊是 O(1)的時間復雜度，同時元素空間可以重復利用。
需要使用sendIndex，receIndex來標記實際的待插入/拉取位置，顯而易見會出現(xiàn) sendIndex<=receIndex 的情況。

recvq,receq是由鏈表實現(xiàn)的隊列，用于存儲阻塞等待的goroutine和待發(fā)送/待接收值， 這兩個結構也是阻塞goroutine被喚醒的準備條件。

3. 發(fā)送/接收的細節(jié)

① 不要使用共享內存來通信，而是使用通信來共享內存

元素值從外界進入信道會被復制，也就是說進入信道的是元素值的副本，并不是元素本身進入信道 (出信道類似)。

金玉良言落到實處：不同的線程不共享內存、不用鎖，線程之間通訊用channel同步也用channel。發(fā)送/接收數(shù)據(jù)的兩個動作(G1,G2,G3)沒有共享的內存，底層通過hchan結構體的buf，使用copy內存的方式進行通信，最后達到了共享內存的目的。

②  根據(jù)第①點，發(fā)送操作包括：復制待發(fā)送值，放置到信道內；
接收操作包括:復制元素值， 放置副本到接收方，刪除原值，以上行為在全部完成之前都不會被打斷。所以第①點所說的無鎖，其實指的業(yè)務代碼無鎖，信道底層實現(xiàn)還是靠鎖。

以send操作為例，下面代碼截取自 https://github.com/golang/go/blob/master/src/runtime/chan.go#L216

if c.qcount < c.dataqsiz {
   // Space is available in the channel buffer. Enqueue the element to send.
   qp := chanbuf(c, c.sendx)         // 計算出buf中待插入位置的地址
   if raceenabled {
    racenotify(c, c.sendx, nil)
   }
   typedmemmove(c.elemtype, qp, ep)  // 將元素copy進指定的qp地址
   c.sendx++                         // 重新計算待插入位置的索引
   if c.sendx == c.dataqsiz {
    c.sendx = 0                      
   }
   c.qcount++
   unlock(&c.lock)
   return true
  }

一個常規(guī)的send動作：

• 計算環(huán)形隊列的待插入位置的地址
• 將元素copy進指定的qp地址
• 重新計算待插入位置的索引sendx
• 如果待插入位置==隊列長度，說明插入位置已到尾部，需要插入首部。
• 以上動作加鎖

③ 進入等待狀態(tài)的goroutine會進入hchan的sendq/recvq列表

調度器將G1、G2置為waiting狀態(tài)，G1、G2進入sendq列表，同時與邏輯處理器分離；

直到有G3嘗試讀取信道內`recvx`元素^[2]，之后將喚醒^[3]隊首G1^[4]進入runnable狀態(tài)，加入調度器的runqueue。

這里面涉及gopark, goready兩個函數(shù)。

如果是無緩沖信道引起的阻塞，將會直接拷貝G1的待發(fā)送值到G2的存儲位置^[5]

?? https://github.com/golang/go/blob/master/src/runtime/chan.go#L527

package main

import (
 "fmt"
 "time"
)

func SendDataToChannel(ch chan int, value int) {
 time.Sleep(time.Millisecond * time.Duration(value))
 ch <- value
}

func main() {
 var v int
 var ch chan int = make(chan int)
 go SendDataToChannel(ch, 104) // 通過信道發(fā)送數(shù)據(jù)
 go SendDataToChannel(ch, 100) // 通過信道發(fā)送數(shù)據(jù)
 go SendDataToChannel(ch, 95)  // 通過信道發(fā)送數(shù)據(jù)
 go SendDataToChannel(ch, 120) // 通過信道發(fā)送數(shù)據(jù)

 time.Sleep(time.Second)
 v = <-ch       //  從信道接受數(shù)據(jù)
 fmt.Println(v)  

 time.Sleep(time.Second * 10)
}

Q3：上述代碼大概率穩(wěn)定輸出95。

A：雖然4個goroutine被啟動的順序不定，但是肯定都阻塞了，阻塞的時機不一樣，被喚醒的是sendq隊首的goroutine，基本可認為第三個goroutine被首先捕獲進sendq ，因為是無緩沖信道，將會直接拷貝G3的95給到待接收地址。

4. 業(yè)內總結的信道的常規(guī)姿勢

無緩沖、緩沖信道的特征，已經在golang領域形成了特定的套路。

• 當容量為0時，說明信道中不能存放數(shù)據(jù)，在發(fā)送數(shù)據(jù)時，必須要求立馬有人接收，此時的信道稱之為無緩沖信道。

• 當容量為1時，說明信道只能緩存一個數(shù)據(jù)，若信道中已有一個數(shù)據(jù)，此時再往里發(fā)送數(shù)據(jù)，會造成程序阻塞，利用這點可以利用信道來做鎖。

• 當容量大于1時，信道中可以存放多個數(shù)據(jù)，可以用于多個協(xié)程之間的通信管道，共享資源。

Q4：為什么無緩沖信道不適合做鎖？

A：我們先思考一下鎖的業(yè)務實質：獲取獨占標識，并能夠繼續(xù)執(zhí)行；無緩沖信道雖然可以獲取獨占標識，但是他阻塞了自身goroutine的執(zhí)行，所以并不適合實現(xiàn)業(yè)務鎖。

參考資料