Go 羣友提問:進程、線程都有 ID,爲什麼 Goroutine 沒有 ID?

大家好,我是煎魚。

最近金三銀四,是面試的季節。在我的 Go 讀者交流羣裏出現了許多小夥伴在討論自己面試過程中所遇到的一些 Go 面試題。如果大家也有疑問,歡迎關注提給我:

公衆號

今天的主角,是大家在既有語言基礎的情況下,學 Goroutine 時會容易糾結的一點。就是 “進程、線程都有 ID,爲什麼 Goroutine 沒有 GoroutineID?”。

這是爲什麼呢,怎麼做那些跨協程處理呢?

GoroutineID 是什麼

我們要知道,爲什麼大家會下意識的想去要 GoroutineID,下面引用 Go 語言聖經中的表述:

在大多數支持多線程的操作系統和程序語言中,當前的線程都有一個獨特的身份(ID),並且這個身份信息可以以一個普通值的形式被很容易地獲取到,典型的可以是一個 integer 或者指針值。這種情況下我們做一個抽象化的 thread-local storage(線程本地存儲,多線程編程中不希望其它線程訪問的內容)就很容易,只需要以線程的 ID 作爲 key 的一個 map 就可以解決問題,每一個線程以其 ID 就能從中獲取到值,且和其它線程互不衝突。

也就是指在常規的進程、線程中都有其 ID 的概念,我們可以在程序中通過 ID 來獲取其他進程、線程中的數據,甚至是傳輸數據。就像一把鑰匙一樣,有了他幹啥都可以。

GoroutineID 的概念也是類似的,也就是協程的 ID。我們下意識的就期望通過協程 ID 來進行跨協程的操作。

但,在 Go 語言中 GoroutineID 並沒有顯式獲取的辦法,這就要打個大大的疑惑了。

爲什麼沒有 GoroutineID

爲什麼在 Go 語言中沒有 GoroutineID 呢,是從一開始就沒有的,還是,這樣子設計的原因是什麼呢?

其實 Go 語言在以前是有暴露方法去獲取 GoroutineID 的,但在 Go1.4 後就把該方法給隱藏起來了,不建議大家使用。

也就是明面上沒有 GoroutineID,是一個有意而爲之的行爲。原因是:根據以往的經驗,認爲 thread-local storage 存在被濫用的可能性,且帶來許多不必要的複雜度

簡單來講,Andrew Gerrand 的回答是 ”thread-local storage 的成本遠遠超過了它們的收益。它們只是不適合 Go 語言。”

潛在的問題

濫用的場景

有一個對外提供 HTTP 服務的 Go 應用,也就是 Web Server。Go HTTP Server 都是採取每次請求新起一個協程的方式。

假設可以通過 GoroutineID 進行跨協程操縱,那麼就有可能出現我的 Goroutine,不一定是由 “我” 自己決定的。可能其他正在處理的 GoroutineB 悄悄摸摸的改了我這個 GoroutineA 的行爲。

這就有可能導致一個災難問題,就是出問題時,你不知道是誰動了你的奶酪。查起問題來簡直就是一個災難。

若是自己維護的模塊清楚還起碼知道這事,假設你的前同事剛好離職了,你又在熟悉代碼,一出問題。這鍋那是死死的扣在了你的頭上了。

如何獲取 GoroutineID

剛剛我們提到是在明面上把 GoroutineID 給隱藏了,那暗面呢,是不是有其他辦法可以獲取到?

答案是:可以的。

通過駭客代碼的方式可以獲取到。在 Go 語言的標準庫 http/2 的 gotrack  中,就有提供如下獲取方法:

 1func main() {
 2    go func() {
 3        fmt.Println("腦子進煎魚了的 GoroutineID:", curGoroutineID())
 4    }()
 5
 6    time.Sleep(time.Second)
 7}
 8
 9func curGoroutineID() uint64 {
10    bp := littleBuf.Get().(*[]byte)
11    defer littleBuf.Put(bp)
12    b := *bp
13    b = b[:runtime.Stack(b, false)]
14    // Parse the 4707 out of "goroutine 4707 ["
15    b = bytes.TrimPrefix(b, goroutineSpace)
16    i := bytes.IndexByte(b, ' ')
17    if i < 0 {
18        panic(fmt.Sprintf("No space found in %q", b))
19    }
20    b = b[:i]
21    n, err := parseUintBytes(b, 10, 64)
22    if err != nil {
23        panic(fmt.Sprintf("Failed to parse goroutine ID out of %q: %v", b, err))
24    }
25    return n
26}
27
28var littleBuf = sync.Pool{
29    New: func() interface{} {
30        buf := make([]byte, 64)
31        return &buf
32    },
33}
34
35var goroutineSpace = []byte("goroutine ")
36
37

輸出結果爲:

1腦子進煎魚了的 GoroutineID:18
2
3

結合 curGoroutineID 方法來看,可以通過對 Go 運行時的分析,也就是 runtime.Stack 從而得到 GoroutineID。

其作用,更多的是對進行跟蹤和調試作用居多。因爲官方並沒有根據 GoroutineID 提供一系列跨協程操縱的方法。

也有如下開源庫可以用於獲取 GoroutineID(不過均多年未維護了):

Go 團隊的 Dave Cheney 對其所開源的 GoroutineID 庫,評價:“If you use this package, you will go straight to hell.”:

davecheney/junk

也就是 “如果你使用這個包,你會直接下地獄。“,非常猛了,深深地勸退大家使用。

日常在哪裏常見

如果大家經常做救火隊長,去排查 Go 工程中的問題,例如:錯誤堆棧信息、PProf 性能分析等調試信息。

因此經常看到 GoroutineID,也就是 “goroutine #### […]”。

我們所看到的 #### 就是真實的 GoroutineID,剩餘的信息就是一些堆棧跟蹤和錯誤描述了。

應該使用 GoroutineID 嗎?

從結果來看,肯定是不推薦使用 GoroutineID 了。畢竟沒有什麼特別的好處,Go 團隊也是反對的。

所以一般都會直接回答 ” 無法獲取 GoroutineID“,應當跟從語言設計理念,使用 Share Memory By Communicating 來實現跨協程的操縱會更合理。

總結

今天這篇文章我們根據 GoroutineID 的歷史,作用,原因,駭客方法進行了逐一梳理,摸索了下里面究竟爲何物。

進程、線程、協程的對比是一個面試中常被拿出來問的話題,而 GoroutineID 就是其中一點,這涉及到整個全局上的設計考慮。

你又是否遇到過 GoroutineID 使用和疑問的場景呢,歡迎大家一起留言討論。


本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/qFAtgpbAsHSPVLuo3PYIhg