关于php:背事故分享-6-种常见的-Go-致命错误场景

大家好，我是煎鱼。

有一次事故现场，在紧急复原后，他正在排查代码，查了好一会。我回头一看，这谬误揭示很显著就是致命谬误，较好定位。

但此时，他居然在查 panic-recover 是不是哪里漏了，我示意大受震惊 …

明天就由煎鱼给大家分享一下谬误类型有哪几种，又在什么场景下会触发。

第一种是 Go 中最规范的 error 谬误，其真身是一个 interface{}。

如下：

type error interface {Error() string
}

在日常工程中，咱们只须要创立任意构造体，实现了 Error 办法，就能够认为是 error 谬误类型。

如下：

type errorString struct {s string}

func (e *errorString) Error() string {return e.s}

在内部调用规范库 API，个别如下：

f, err := os.Open("filename.ext")
if err != nil {log.Fatal(err)
}
// do something with the open *File f

咱们会约定最初一个参数为 error 类型，个别常见于第二个参数，能够有个约定俗成的习惯。

第二种是 Go 中的异样解决 panic，可能产生异样谬误，联合 panic+recover 能够扭转程序的运行状态。

如下：

package main

import "os"

func main() {panic("a problem")

    _, err := os.Create("/tmp/file")
    if err != nil {panic(err)
    }
}

输入后果：

$ go run panic.go
panic: a problem
goroutine 1 [running]:
main.main()
    /.../panic.go:12 +0x47
...
exit status 2

如果没有应用 recover 作为捕捉，就会导致程序中断。也因而常常被人误以为程序中断，就 100% 是 panic 导致的。

这是一个误区。

第三种是 Go 初学者常常踩坑，也不晓得的谬误类型，那就是致命谬误 throw。

这个谬误类型，在用户侧是没法被动调用的，均为 Go 底层自行调用的，像是大家常见的 map 并发读写，就是由此触发。

其源码如下：

func throw(s string) {systemstack(func() {print("fatal error:", s, "\n")
    })
    gp := getg()
    if gp.m.throwing == 0 {gp.m.throwing = 1}
    fatalthrow()
    *(*int)(nil) = 0 // not reached
}

根据上述程序，会获取以后 G 的实例，并设置其 M 的 throwing 状态为 1。

状态设置好后，会调用 fatalthrow 办法进行真正的 crash 相干操作：

func fatalthrow() {pc := getcallerpc()
    sp := getcallersp()
    gp := getg()
    
    systemstack(func() {startpanic_m()
        if dopanic_m(gp, pc, sp) {crash()
        }

        exit(2)
    })

    *(*int)(nil) = 0 // not reached
}

主体逻辑是发送 _SIGABRT 信号量，最初调用 exit 办法退出，所以你会发现这是拦也拦不住的“致命”谬误。

为此，作为一名“成熟”的 Go 工程师，除了保障本人程序的健壮性外，我也在网上收集了一些致命的谬误场景，分享给大家。

一起学习和躲避这些致命场景，年底争取拿个 A，不要背上 P0 事变。

func foo() {m := map[string]int{}
    go func() {
        for {m["煎鱼 1"] = 1
        }
    }()
    for {_ = m["煎鱼 2"]
    }
}

输入后果：

fatal error: concurrent map read and map write

goroutine 1 [running]:
runtime.throw(0x1078103, 0x21)
...

func foo() {var f func(a [1000]int64)
    f = func(a [1000]int64) {f(a)
    }
    f([1000]int64{})
}

输入后果：

runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc0200e1bf0 stack=[0xc0200e0000, 0xc0400e0000]
fatal error: stack overflow

runtime stack:
runtime.throw(0x1074ba3, 0xe)
        /usr/local/Cellar/go/1.16.6/libexec/src/runtime/panic.go:1117 +0x72
runtime.newstack()
...

func foo() {var f func()
    go f()}

输入后果：

fatal error: go of nil func value

goroutine 1 [running]:
main.foo()
...

func foo() {select {}
}

输入后果：

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [select (no cases)]:
main.foo()
...

如果你的 goroutines 被 IO 操作阻塞了，新的线程可能会被启动来执行你的其余 goroutines。

Go 的最大的线程数是有默认限度的，如果达到了这个限度，你的应用程序就会解体。

会呈现如下输入后果：

fatal error: thread exhaustion
...

能够通过调用 runtime.SetMaxThreads 办法增大线程数，不过也须要考量是否程序有问题。

如果你执行的操作，例如：下载大文件等。导致应用程序占用内存过大，程序上涨，导致 OOM。

会呈现如下输入后果：

fatal error: runtime: out of memory
...

倡议解决掉一些程序，或者换新电脑了。

在明天这篇文章中，咱们介绍了 Go 语言的三种谬误类型。其中针对大家起码见，但一碰到就很容易翻车的致命谬误 fatal error 进行了介绍，给出了一些经典案例。

心愿大家后续可能躲避，你有没有遇到过其中的场景？

若有任何疑难欢送评论区反馈和交换，最好的关系是相互成就 ，各位的点赞就是煎鱼创作的最大能源，感激反对。

文章继续更新，能够微信搜【脑子进煎鱼了】浏览，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言能够看 Go 学习地图和路线，欢送 Star 催更。

Are all runtime errors recoverable in Go?

关于php:背事故分享-6-种常见的-Go-致命错误场景

谬误类型

error

panic

throw

致命场景

并发读写 map

堆栈内存耗尽

将 nil 函数作为 goroutine 启动

goroutines 死锁

线程限度耗尽

超出可用内存

总结

参考