进程、线程都有 ID，为什么 Goroutine 没有 ID？

た入场券 2022-09-10 14:13 145阅读 0赞

今天的主角，是大家在既有语言基础的情况下，学 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 语言**。”

### 潜在的问题 ###

*  当 Goroutine 消失时：
 *   *  它的 Goroutine 本地存储将不会被 GC 化。(你可以得到 goid 的当前的 Goroutine，但你不能得到所有运行的 Goroutine 的列表)
 *  如果处理程序自己产生了新的 Goroutine 怎么办？
 *   *  新的 Goroutine 失去了对既有的 Goroutine 本地存储。虽然你可以保证自己的代码不会产生其他的 Goroutine。
     *  一般来说，你不能确保标准库或任何第三方代码不会这样做。
 *  Go 应用程序的复杂度和心智负担等上升。

### 滥用的场景 ###

有一个对外提供 HTTP 服务的 Go 应用，也就是 Web Server。Go HTTP Server 都是采取每次请求新起一个协程的方式。

假设可以通过 GoroutineID 进行跨协程操纵，那么就有可能出现我的 Goroutine，不一定是由 “我” 自己决定的。可能其他正在处理的 GoroutineB 悄悄摸摸的改了我这个 GoroutineA 的行为。

这就有可能导致一个灾难问题，就是出问题时，你不知道是谁动了你的奶酪。查起问题来简直就是一个灾难。

若是自己维护的模块清楚还起码知道这事，假设你的前同事刚好离职了，你又在熟悉代码，一出问题。这锅那是死死的扣在了你的头上了。

## 如何获取 GoroutineID ##

刚刚我们提到是在明面上把 GoroutineID 给隐藏了，那暗面呢，是不是有其他办法可以获取到？

答案是：可以的。

通过骇客代码的方式可以获取到。在 Go 语言的标准库 http/2 的 gotrack  中，就有提供如下获取方法：

func main() {
        go func() {
            fmt.Println("脑子进煎鱼了的 GoroutineID：", curGoroutineID())
        }()
    
        time.Sleep(time.Second)
    }
    
    func curGoroutineID() uint64 {
        bp := littleBuf.Get().(*[]byte)
        defer littleBuf.Put(bp)
        b := *bp
        b = b[:runtime.Stack(b, false)]
        // Parse the 4707 out of "goroutine 4707 ["
        b = bytes.TrimPrefix(b, goroutineSpace)
        i := bytes.IndexByte(b, ' ')
        if i < 0 {
            panic(fmt.Sprintf("No space found in %q", b))
        }
        b = b[:i]
        n, err := parseUintBytes(b, 10, 64)
        if err != nil {
            panic(fmt.Sprintf("Failed to parse goroutine ID out of %q: %v", b, err))
        }
        return n
    }
    
    var littleBuf = sync.Pool{
        New: func() interface{} {
            buf := make([]byte, 64)
            return &buf
        },
    }
    
    var goroutineSpace = []byte("goroutine ")

输出结果为：

脑子进煎鱼了的 GoroutineID：18

结合 `curGoroutineID` 方法来看，可以通过对 Go 运行时的分析，也就是 `runtime.Stack` 从而得到 GoroutineID。

其作用，更多的是对进行跟踪和调试作用居多。因为官方并没有根据 GoroutineID 提供一系列跨协程操纵的方法。

也有如下开源库可以用于获取 GoroutineID（不过均多年未维护了）：

*  davecheney/junk
 *  jtolio/gls
 *  tylerstillwater/gls

Go 团队的 Dave Cheney 对其所开源的 GoroutineID 库，评价：“If you use this package, you will go straight to hell.”：

![b3493f239ad2b324abf086bc9e63a67b.png][] davecheney/junk

也就是 “如果你使用这个包，你会直接下地狱。“，非常猛了，深深地劝退大家使用。

## 日常在哪里常见 ##

如果大家经常做救火队长，去排查 Go 工程中的问题，例如：错误堆栈信息、PProf 性能分析等调试信息。

因此经常看到 GoroutineID，也就是 “`goroutine ####` \[…\]”。