Go 面试官：进程、线程都有 ID，为何 Goroutine 没有 ID？

微信搜索【 脑子进煎鱼了】关注这一只爆肝煎鱼。本文 GitHub eddycjy/blog 已收录，有个人系列文章、资料和开源 Go 图书。

你们好，我是煎鱼。

最近金三银四，是面试的季节。在个人 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 语言。”

潜在的问题

• 当 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.”：

也就是 “若是你使用这个包，你会直接下地狱。“，很是猛了，深深地劝退你们使用。

平常在哪里常见

若是你们常常作救火队长，去排查 Go 工程中的问题，例如：错误堆栈信息、PProf 性能分析等调试信息。

所以常常看到 GoroutineID，也就是 “goroutine #### […]”。

咱们所看到的 #### 就是真实的 GoroutineID，剩余的信息就是一些堆栈跟踪和错误描述了。

应该使用 GoroutineID 吗？

从结果来看，确定是不推荐使用 GoroutineID 了。毕竟没有什么特别的好处，Go 团队也是反对的。

因此通常都会直接回答 ”没法获取 GoroutineID“，应当跟从语言设计理念，使用 Share Memory By Communicating 来实现跨协程的操纵会更合理。

总结

今天这篇文章咱们根据 GoroutineID 的历史，做用，缘由，骇客方法进行了逐一梳理，摸索了下里面究竟为什么物。

进程、线程、协程的对比是一个面试中常被拿出来问的话题，而 GoroutineID 就是其中一点，这涉及到整个全局上的设计考虑。

你又是否遇到过 GoroutineID 使用和疑问的场景呢，欢迎你们一块儿留言讨论。

文章持续更新，能够微信搜【脑子进煎鱼了】阅读，回复【 000】有我准备的一线大厂面试算法题解和资料；本文 GitHub eddycjy/blog 已收录，欢迎 Star 催更。