走進Golang之Channel的數據結構

上篇文章講了 channel 的基本使用,講了一些使用時需要注意的事項,本文將重點介紹 channel 中的兩個數據結構:循環隊列雙端鏈表

channel 的需求描述

爲了理解這些數據結構解決了什麼問題,我們先來做個簡單的回顧,看看爲什麼需要這兩個數據結構,他們解決了什麼問題。我們知道 goroutine 是用戶態的線程,不同的 goroutine 之間是有消息傳遞這個需求的。在原始的進程與線程(系統線程)編程中我們會採用管道的方式,而 channel 就是用戶態線程傳遞消息的管道實現,並且是類型安全的。

既然 channel 是一個管道,用來滿足不同 goroutine 間交換消息的。那麼實現這樣一個管道要怎麼做呢?

來看看我們日常傳遞消息的需求:

  1. 能夠有多個 goroutinechannel 進行讀寫,並且保證沒有競爭問題,需要用 隊列 來管理阻塞的 goroutine,解決競爭問題;

  2. 需要管理髮送到 channel 的消息(有緩衝、無緩衝),對於有緩存的 channel 可以採用 循環隊列 來管理多個消息。

當然上面的需求是經過簡化的,比如 channel 還需要具備阻塞、喚醒 goroutine 的能力,不過爲了本文我們更加專注焦點問題,先只關注上面兩個問題。

channel 的數據結構

接下來我們分析一下 channel 在實際運行中,它的結構體是怎麼樣的。當然這又分爲兩種類型,有緩衝與無緩衝的。我們先來看一個無緩衝的情況。

無緩衝

先把示例代碼貼出來。就是兩個讀的 goroutine 被阻塞在一個無緩衝的 channel 上。

func main() {
 ch := make(chan int) // 無緩衝

 go goRoutineA(ch)
 go goRoutineB(ch)
 ch <- 1

 time.Sleep(time.Second * 1)
}

func goRoutineA(ch chan int) {
 v := <-ch
 fmt.Printf("A received data: %d\n", v)
}

func goRoutineB(ch chan int) {
 v := <-ch
 fmt.Printf("B received data: %d\n", v)
}

來看看當代碼執行到 ch <- 1 這一行之後 channel 的結構體被填充成什麼樣子了!

無緩衝 channel

注意其中 buf 字段可存儲的長度是0,這是因爲 無緩衝 channel 不會用到循環隊列來存儲數據。它一定是等讀、寫 goroutine 都準備好了,然後直接把數據交給對方。我們用一副圖來看一下無緩衝的數據交換過程。

交換數據

上圖描述的是數據交換過程,再看一下讀 goroutine 被阻塞的結構示意圖。被阻塞的 goroutine 會掛載到對應的隊列上,該隊列是一個雙端隊列。

上面的例子,由於兩個讀 goroutine 在啓動的時候,寫還沒有準備好,因此讀全部被掛起在隊列中;當有寫goroutine準備好的時候,由於此時讀已經就緒,因此寫不會阻塞,掛起放到 sendq 中。大家可以修改上面的代碼,自己看一下寫阻塞,讀立馬執行的情況。

結構示例

有緩衝

我們將上面的代碼改成有緩衝的通道,然後再來看看有緩衝的情況。

func main() {
 ch := make(chan int, 3) // 有緩衝

 // 都不會阻塞
 ch <- 1
 ch <- 2
    ch <- 3
    // 會阻塞,被掛起到 sendq 中
 go func() {
  ch <- 4
 }()

 // 只是爲了debug
 var a int
 fmt.Println(a)

 go goRoutineA(ch)
 go goRoutineA(ch)
 go goRoutineB(ch)
 go goRoutineB(ch) // 猜猜這裏會被掛起嗎?

 time.Sleep(time.Second * 2)
}

func goRoutineA(ch chan int) {
 v := <-ch
 fmt.Printf("A received data: %d\n", v)
}

func goRoutineB(ch chan int) {
 v := <-ch
 fmt.Printf("B received data: %d\n", v)
}

貼出執行到第一行的 go goRoutineA(ch) 時, hchan 的結構填充情況。

有緩衝 channel

在這裏可以看到緩衝的大小是3,由於增加了緩衝,只要寫 goroutine 沒有把緩衝寫滿,則不會導致協程阻塞。但是一旦緩衝沒有多餘的空間,則會把寫 goroutine 掛起到 sendq 中,直到有空間時將他喚醒(還有其它喚醒的場景,這一略過)。

其實有緩衝的 channel,就是把同步的通信變爲了異步的通信。寫的 channel 不需要關注讀 channel,只要有空間它就寫;而讀也一樣,只要有數據就正常讀就可以,如果沒有就掛起到隊列中,等待被喚醒。下圖形象的展示了有緩衝 channel 是如何交換數據的。

交換數據

我們再來用圖的形式看一下此時結構體的樣子,這裏圖有些偷懶,只是在上面圖的基礎上增加了循環隊列部分的描述,實際到該例子中,讀 goroutine時不會被阻塞的,看的時候需要注意這一點。

結構示例

循環隊列

今天最重要的是理解 channel 中兩個關鍵的數據結構。爲了下一講閱讀源碼做準備,我把 channel 中的循環隊列部分的代碼抽象出來了。

// 隊列滿了
var ErrQFull = errors.New("circular is full")

// 沒有值
var ErrQEmpty = errors.New("circular is empty")

// 定義循環隊列
// 如何確定隊空,還是隊滿?q.sendx = (q.sendx+1) % q.dataqsiz
type queue struct {
 buf      []int // 隊列元素存儲
 dataqsiz uint  // circular 隊列長度
 qcount   uint  // 有多少元素在buf中 qcount = len(buf)
 sendx    uint  // 可以理解爲隊尾指針,向隊列寫入數據
 recvx    uint  // 可以理解爲隊頭指針,從隊列讀取數據
}

func makeQ(size int) *queue {
 q := &queue{
  dataqsiz: uint(size),
  buf:      nil,
 }

 q.buf = make([]int, q.dataqsiz)

 return q
}

// 向buf中寫入數據
// 請看 chansend 函數
func (c *queue) insert(ele int) error {
 // 檢查隊列是否有空間
 if c.dataqsiz > 0 && c.qcount == c.dataqsiz {
  return ErrQFull
 }

 // 存入數據
 c.buf[c.sendx] = ele
 c.sendx++                  // 尾指針後移
 if c.sendx == c.dataqsiz { // 如果相等,說明隊列寫滿了,sendx放到開始位置
  c.sendx = 0
 }
 c.qcount++

 return nil
}

// 從buf中讀取數據
func (c *queue) read() (int, error) {
 // 隊列中沒有數據了
 if c.dataqsiz > 0 && c.qcount == 0 {
  return 0, ErrQEmpty
 }

 ret := c.buf[c.recvx] // 取出元素
 c.buf[c.recvx] = 0
 c.recvx++
 if c.recvx == c.dataqsiz { // 如果相等,說明寫到末尾了,recvx放到開始位置
  c.recvx = 0
 }
 c.qcount--

 return ret, nil
}

上面的代碼基本上就是 channel 的循環隊列部分的實現。這個隊列的實現與我們平常實現的循環隊列稍微有些不一樣。一般我們爲了方便判空,會浪費一個buf的空間來方便判空,公式是:(tail+1)%n=head ;但是在 channel 這裏的循環隊列,由於有了一個循環隊列元素的計數,確保了這個空間不會被浪費,並且同時也能夠滿足 O(1) 時間複雜度計算有緩衝 channel 元素個數。

總結

總結一下今天的主要信息。

  1. channel 中用到了兩個數據結構:循環隊列雙端鏈表

  2. 循環隊列 只有在有緩衝 channel 中才會使用,它主要是做爲消息的緩衝、保證消息的有序性;

  3. 雙端鏈表 是用來掛起阻塞的讀、寫 goroutine 的,在被喚醒時會按照入隊順序公平的進行通知;

  4. 無緩衝的 channel 不會用到 循環隊列 相關的結構,它必須讀寫 goroutine 都準備好後才能進行消息交換;

  5. 做爲緩衝消息的 循環隊列 通過一個當前元素個數字段的標記,避免了浪費一個數據空間。

下一章我們就嘗試閱讀一下 channel 的源碼,想要嘗試錄製一個視頻來講這部分源碼!

參考資料

  • [1] [Diving Deep Into The Golang Channels.](https://codeburst.io/diving-deep-into-the-golang-channels-549fd4ed21a8)

  • [2] [Understanding Channels](https://speakerdeck.com/kavya719/understanding-channels)

  • [3] [The Nature Of Channels In Go](https://www.ardanlabs.com/blog/2014/02/the-nature-of-channels-in-go.html)


推薦閱讀


程序改變的不止是世界

也改變了你我的頭髮

公衆號ID

dayuTalk

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章