goroutine 为何会饿死？

目前golang学习网上已经有很多关于Golang的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《goroutine 为何会饿死？》，也希望能帮助到大家，如果阅读完后真的对你学习Golang有帮助，欢迎动动手指，评论留言并分享~

我的客户端相当简单。还有两个 goroutine：

1. 主 goroutine：只是“for”循环，但带有调用函数。
2. 第二个 goroutine：这个 goroutine 只是恐慌。

package main

import (
    "runtime"
)

func main() {
    runtime.gomaxprocs(1)
    go func() {
        panic(1)
    }()
    for {
        test()
    }
}

func test() {
    _ = make([]byte, 200)
    a := 1
    for {
        a++
        if a == 10 {
            break
        }
    }
}

我的golang版本是go1.14.3。

主协程中存在未内联且规模不小的函数调用，因此主协程应被 sysmon 抢占。第二个 goroutine 将有机会执行，并发生恐慌。

但是什么也没发生。请帮忙！

GODEBUG=asyncpreemptoff=1 go run main.go

解决方案

好吧，我必须首先指出，这个问题确实不适合 so，因为它暗示了某种讨论 - 这已经在问题原始版本的评论中发生过， - 并且应该更好改为询问the mailing list。

但是好吧，让我们尝试解决您的问题的 v2，其中包含以下代码：

package main

import (
    "runtime"
)

func main() {
    runtime.gomaxprocs(1)
    go func() {
        panic(1)
    }()
    for {
        test()
    }
}

func test() {
    _ = make([]byte, 200)
    a := 1
    for {
        a++
        if a == 10 {
            break
        }
    }
}

如果我们要求编译器转储它为您的程序生成的汇编代码 - 通过运行

go build -gcflags=-s preempt.go 2>preempt.s

（转储到 stderr，这就是为什么 2>...），在 linux/amd64 和 go 1.14.3 上，我们将得到（省略）：

# command-line-arguments
"".main stext size=80 args=0x0 locals=0x18
    0x0000 00000 (preempt.go:7) text    "".main(sb), abiinternal, $24-0
    0x0000 00000 (preempt.go:7) movq    (tls), cx
    0x0009 00009 (preempt.go:7) cmpq    sp, 16(cx)
    0x000d 00013 (preempt.go:7) jls 73
    0x000f 00015 (preempt.go:7) subq    $24, sp
    0x0013 00019 (preempt.go:7) movq    bp, 16(sp)
    0x0018 00024 (preempt.go:7) leaq    16(sp), bp
    0x001d 00029 (preempt.go:7) funcdata    $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(sb)
    0x001d 00029 (preempt.go:7) funcdata    $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(sb)
    0x001d 00029 (preempt.go:7) funcdata    $2, gclocals·9fb7f0986f647f17cb53dda1484e0f7a(sb)
    0x001d 00029 (preempt.go:8) pcdata  $0, $0
    0x001d 00029 (preempt.go:8) pcdata  $1, $0
    0x001d 00029 (preempt.go:8) movq    $1, (sp)
    0x0025 00037 (preempt.go:8) call    runtime.gomaxprocs(sb)
    0x002a 00042 (preempt.go:9) movl    $0, (sp)
    0x0031 00049 (preempt.go:9) pcdata  $0, $1
    0x0031 00049 (preempt.go:9) leaq    "".main.func1·f(sb), ax
    0x0038 00056 (preempt.go:9) pcdata  $0, $0
    0x0038 00056 (preempt.go:9) movq    ax, 8(sp)
    0x003d 00061 (preempt.go:9) call    runtime.newproc(sb)
    0x0042 00066 (preempt.go:13)    call    "".test(sb)
    0x0047 00071 (preempt.go:13)    jmp 66
    0x0049 00073 (preempt.go:13)    nop
    0x0049 00073 (preempt.go:7) pcdata  $1, $-1
    0x0049 00073 (preempt.go:7) pcdata  $0, $-1
    0x0049 00073 (preempt.go:7) call    runtime.morestack_noctxt(sb)
    0x004e 00078 (preempt.go:7) jmp 0
<…>
"".test stext nosplit size=17 args=0x0 locals=0x0
    0x0000 00000 (preempt.go:17)    text    "".test(sb), nosplit|abiinternal, $0-0
    0x0000 00000 (preempt.go:17)    funcdata    $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(sb)
    0x0000 00000 (preempt.go:17)    funcdata    $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(sb)
    0x0000 00000 (preempt.go:17)    funcdata    $2, gclocals·33cdeccccebe80329f1fdbee7f5874cb(sb)
    0x0000 00000 (preempt.go:17)    pcdata  $0, $0
    0x0000 00000 (preempt.go:17)    pcdata  $1, $0
    0x0000 00000 (preempt.go:17)    movl    $1, ax
    0x0005 00005 (preempt.go:20)    jmp 10
    0x0007 00007 (preempt.go:21)    incq    ax
    0x000a 00010 (preempt.go:22)    cmpq    ax, $9
    0x000e 00014 (preempt.go:22)    jne 7
    0x0010 00016 ()    pcdata  $0, $-2
    0x0010 00016 ()    pcdata  $1, $-2
    0x0010 00016 ()    ret
<…>

这里的列表从 main 的主体开始，然后继续 test 的主体。

在 main 中，最令人感兴趣的是以下部分：

0x0042 00066 (preempt.go:13)    call    "".test(sb)
    0x0047 00071 (preempt.go:13)    jmp 66

这基本上是你的 for 循环变成了 call 到 test 函数，然后是无条件 jmp 到 call 的地址。

如您所见，目前还没有任何有助于抢占的代码。

现在让我们看看 test 的代码。

首先要注意的是，看不到切片分配的痕迹：它已被优化掉。

但是现在让我们看一下该函数的有点神秘的声明：

0x0000 00000 (preempt.go:17)    TEXT    "".Test(SB), NOSPLIT|ABIInternal, $0-0

最有趣的是 nosplit 位。
如果我们查询the docs on the Go's assembler，我们会发现

很难理解为什么它被这样称呼并提到“拆分”，但那是从 go 的 goroutine 具有“拆分堆栈”的时代开始的：也就是说，当 goroutine 的堆栈必须增长并且没有可用空间时其中，将为其分配另一个“块”，并链接到原始块；该过程可能会重复多次，从而产生多段、分裂、堆栈。因此得名。
后来在 go 的开发周期 goroutine stacks became contiguous and reallocatable 中（很像支持切片数组），但为了向后兼容，保留了这个模糊标识符的名称。

好的，事情是这样的：编译器注意到函数 test 不会在其堆栈上分配任何内容，因此它永远不会使用超出其自己的堆栈帧（由调用者分配）之外的任何堆栈空间，因此编译器并将该函数标记为 nosplit，以消除任何需要增长堆栈的运行时检查，从而提高调用速度。

这就是您在运行时观察到的情况。

如果您感兴趣，您可以通过运行 go 工具 objdump 来反汇编已构建的可执行映像。
它对于分析来说也相当不错，但包含很多垃圾，因为链接的所有运行时、stdlib 和初始化代码都与您自己的代码一起反汇编，您需要在转储中搜索这些代码。

以上就是《goroutine 为何会饿死？》的详细内容，更多关于的资料请关注golang学习网公众号！