第七章：进阶内容

1 理清 Go 中晦涩难懂的寻址问题

1.1 什么叫可寻址？

可直接使用 & 操作符取地址的对象，就是可寻址的（Addressable）。比如下面这个例子

func main() {
    name := "iswbm"
    fmt.Println(&name)
    // output: 0xc000010200
}

程序运行不会报错，说明 name 这个变量是可寻址的。
但不能说 "iswbm" 这个字符串是可寻址的。
"iswbm" 是字符串，字符串都是不可变的，是不可寻址的，后面会介绍到。
在开始逐个介绍之前，先说一下结论

指针可以寻址：&Profile{}
变量可以寻址：name := Profile{}
字面量通通不能寻址：Profile{}

1.2 哪些是可以寻址的？

变量：&x

func main() {
    name := "iswbm"
    fmt.Println(&name)
    // output: 0xc000010200
}

指针：&*x

type Profile struct {
    Name string
}

func main() {
    fmt.Println(unsafe.Pointer(&Profile{Name: "iswbm"}))
    // output: 0xc000108040
}

数组元素索引: &a[0]

func main() {
    s := [...]int{1,2,3}
    fmt.Println(&s[0])
    // output: xc0000b4010
}

切片

func main() {
    fmt.Println([]int{1, 2, 3}[1:])
}

切片元素索引：&s[1]

func main() {
    s := make([]int , 2, 2)
    fmt.Println(&s[0])
    // output: xc0000b4010
}

组合字面量: &struct{X type}

所有的组合字面量都是不可寻址的，就像下面这样子

type Profile struct {
    Name string
}

func new() Profile {
    return Profile{Name: "iswbm"}
}

func main() {
    fmt.Println(&new())
    // cannot take the address of new()
}

注意上面写法与这个写法的区别，下面这个写法代表不同意思，其中的 & 并不是取地址的操作，而代表实例化一个结构体的指针。

type Profile struct {
    Name string
}

func main() {
    fmt.Println(&Profile{Name: "iswbm"}) // ok
}

虽然组合字面量是不可寻址的，但却可以对组合字面量的字段属性进行寻址（直接访问）

type Profile struct {
    Name string
}

func new() Profile {
    return Profile{Name: "iswbm"}
}

func main() {
    fmt.Println(new().Name)
}

1.3 哪些是不可以寻址的？

常量

import "fmt"

const VERSION  = "1.0"

func main() {
    fmt.Println(&VERSION)
}

字符串

func getStr() string {
    return "iswbm"
}
func main() {
    fmt.Println(&getStr())
    // cannot take the address of getStr()
}

函数或方法

func getStr() string {
    return "iswbm"
}
func main() {
    fmt.Println(&getStr)
    // cannot take the address of getStr
}

基本类型字面量

字面量分：基本类型字面量 和 复合型字面量。
基本类型字面量，是一个值的文本表示，都是不应该也是不可以被寻址的。

func getInt() int {
    return 1024
}

func main() {
    fmt.Println(&getInt())
    // cannot take the address of getInt()
}

map 中的元素

字典比较特殊，可以从两个角度来反向推导，假设字典的元素是可寻址的，会出现什么问题？

如果字典的元素不存在，则返回零值，而零值是不可变对象，如果能寻址问题就大了。
而如果字典的元素存在，考虑到 Go 中 map 实现中元素的地址是变化的，这意味着寻址的结果也是无意义的。

基于这两点，Map 中的元素不可寻址，符合常理。

func main() {
    p := map[string]string {
        "name": "iswbm",
    }

    fmt.Println(&p["name"])
    // cannot take the address of p["name"]
}

搞懂了这点，你应该能够理解下面这段代码为什么会报错啦~

package main

import "fmt"

type Person struct {
    Name  string
    Email string
}

func main() {
    m := map[int]Person{
        1:Person{"Andy", "1137291867@qq.com"},
        2:Person{"Tiny", "qishuai231@gmail.com"},
        3:Person{"Jack", "qs_edu2009@163.com"},
    }

    //编译错误：cannot assign to struct field m[1].Name in map
    m[1].Name = "Scrapup"

数组字面量

数组字面量是不可寻址的，当你对数组字面量进行切片操作，其实就是寻找内部元素的地址，下面这段代码是会报错的

func main() {
    fmt.Println([3]int{1, 2, 3}[1:])
    // invalid operation [3]int literal[1:] (slice of unaddressable value)
}

2 学习 Go 语言中边界检查

2.1 什么是边界检查？

边界检查，英文名 Bounds Check Elimination，简称为 BCE。它是 Go 语言中防止数组、切片越界而导致内存不安全的检查手段。如果检查下标已经越界了，就会产生 Panic。
边界检查使得我们的代码能够安全地运行，但是另一方面，也使得我们的代码运行效率略微降低。
比如下面这段代码，会进行三次的边界检查

package main

func f(s []int) {
    _ = s[0]  // 检查第一次
    _ = s[1]  // 检查第二次
    _ = s[2]  // 检查第三次
}

func main() {}

你可能会好奇了，三次？我是怎么知道它要检查三次的。
实际上，你只要在编译的时候，加上参数即可，命令如下

$ go build -gcflags="-d=ssa/check_bce/debug=1" main.go
# command-line-arguments
./main.go:4:7: Found IsInBounds
./main.go:5:7: Found IsInBounds
./main.go:6:7: Found IsInBounds

2.2 边界检查的条件？

并不是所有的对数组、切片进行索引操作都需要边界检查。
比如下面这个示例，就不需要进行边界检查，因为编译器根据上下文已经得知，s 这个切片的长度是多少，你的终止索引是多少，立马就能判断到底有没有越界，因此是不需要再进行边界检查，因为在编译的时候就已经知道这个地方会不会 panic。

package main

func f() {
    s := []int{1,2,3,4}
    _ = s[:9]  // 不需要边界检查
}
func main()  {}

因此可以得出结论，对于在编译阶段无法判断是否会越界的索引操作才会需要边界检查，比如这样子

package main


func f(s []int) {
    _ = s[:9]  // 需要边界检查
}
func main()  {}

2.3 边界检查的特殊案例

案例一

在如下示例代码中，由于索引 2 在最前面已经检查过会不会越界，因此聪明的编译器可以推断出后面的索引 0 和 1 不用再检查啦

package main

func f(s []int) {
    _ = s[2] // 检查一次
    _ = s[1]  // 不会检查
    _ = s[0]  // 不会检查
}

func main() {}

案例二

在下面这个示例中，可以在逻辑上保证不会越界的代码，同样是不会进行越界检查的。

package main

func f(s []int) {
    for index, _ := range s {
        _ = s[index]
        _ = s[:index+1]
        _ = s[index:len(s)]
    }
}

func main()  {}

案例三

在如下示例代码中，虽然数组的长度和容量可以确定，但是索引是通过 rand.Intn() 函数取得的随机数，在编译器看来这个索引值是不确定的，它有可能大于数组的长度，也有可能小于数组的长度。
因此第一次是需要进行检查的，有了第一次检查后，第二次索引从逻辑上就能推断，所以不会再进行边界检查。

package main

import (
    "math/rand"
)

func f()  {
    s := make([]int, 3, 3)
    index := rand.Intn(3)
     _ = s[:index]  // 第一次检查
    _ = s[index:]  // 不会检查
}

func main()  {}

但如果把上面的代码稍微改一下，让切片的长度和容量变得不一样，结果又会变得不一样了。

package main

import (
    "math/rand"
)

func f()  {
    s := make([]int, 3, 5)
    index := rand.Intn(3)
     _ = s[:index]  // 第一次检查
    _ = s[index:]  // 第二次检查
}

func main()  {}

我们只有当数组的长度和容量相等时， :index 成立，才能一定能推出 index: 也成立，这样的话，只要做一次检查即可
一旦数组的长度和容量不相等，那么 index 在编译器看来是有可能大于数组长度的，甚至大于数组的容量。
我们假设 index 取得的随机数为 4，那么它大于数组长度，此时 s[:index] 虽然可以成功，但是 s[index:] 是要失败的，因此第二次边界的检查是有必要的。
你可能会说， index 不是最大值为 3 吗？怎么可能是 4呢？
要知道编译器在编译的时候，并不知道 index 的最大值是 3 呢。
小结一下

当数组的长度和容量相等时，s[:index] 成立能够保证 s[index:] 也成立，因为只要检查一次即可
当数组的长度和容量不等时，s[:index] 成立不能保证 s[index:] 也成立，因为要检查两次才可以

案例四

有了上面的铺垫，再来看下面这个示例，由于数组是调用者传入的参数，所以编译器的编译的时候无法得知数组的长度和容量是否相等，因此只能保险一点，两个都检查。

package main

import (
    "math/rand"
)

func f(s []int, index int) {
    _ = s[:index] // 第一次检查
    _ = s[index:] // 第二次检查
}

func main()  {}

但是如果把两个表达式的顺序反过来，就只要做一次检查就行了，原因我就不赘述了。

package main

import (
    "math/rand"
)

func f(s []int, index int) {
    _ = s[index:] // 第一次检查
    _ = s[:index] // 不用检查
}

func main()  {}

2.4 主动消除边界检查

虽然编译器已经非常努力去消除一些应该消除的边界检查，但难免会有一些遗漏。
这就需要”警民合作”，对于那些编译器还未考虑到的场景，但开发者又极力追求程序的运行效率的，可以使用一些小技巧给出一些暗示，告诉编译器哪些地方可以不用做边界检查。
比如下面这个示例，从代码的逻辑上来说，是完全没有必要做边界检查的，但是编译器并没有那么智能，实际上每个for循环，它都要做一次边界的检查，非常的浪费性能。

package main


func f(is []int, bs []byte) {
    if len(is) >= 256 {
        for _, n := range bs {
            _ = is[n] // 每个循环都要边界检查
        }
    }
}
func main()  {}

可以试着在 for 循环前加上这么一句 is = is[:256] 来告诉编译器新 is 的长度为 256，最大索引值为 255，不会超过 byte 的最大值，因为 is[n] 从逻辑上来说是一定不会越界的。

package main


func f(is []int, bs []byte) {
    if len(is) >= 256 {
        is = is[:256]
        for _, n := range bs {
            _ = is[n] // 不需要做边界检查
        }
    }
}
func main()  {}

3 Go 语言中的内存分配规律及逃逸分析

3.1 分配内存三大组件

Go 分配内存的过程，主要由三大组件所管理，级别从上到下分别是：

mheap

Go 在程序启动时，首先会向操作系统申请一大块内存，并交由mheap结构全局管理。
具体怎么管理呢？ mheap 会将这一大块内存，切分成不同规格的小内存块，我们称之为 mspan，根据规格大小不同，mspan 大概有 70类左右，划分得可谓是非常的精细，足以满足各种对象内存的分配。
那么这些 mspan 大大小小的规格，杂乱在一起，肯定很难管理对吧？
因此就有了 mcentral 这下一级组件

mcentral

启动一个 Go 程序，会初始化很多的 mcentral ，每个 mcentral 只负责管理一种特定规格的 mspan。
相当于 mcentral 实现了在 mheap 的基础上对 mspan 的精细化管理。
但是 mcentral 在 Go 程序中是全局可见的，因此如果每次协程来 mcentral 申请内存的时候，都需要加锁。
可以预想，如果每个协程都来 mcentral 申请内存，那频繁的加锁释放锁开销是非常大的。
因此需要有一个 mcentral 的二级代理来缓冲这种压力

mcache

在一个 Go 程序里，每个线程M会绑定给一个处理器P，在单一粒度的时间里只能做多处理运行一个goroutine，每个P都会绑定一个叫 mcache 的本地缓存。
当需要进行内存分配时，当前运行的goroutine会从mcache中查找可用的mspan。从本地mcache里分配内存时不需要加锁，这种分配策略效率更高。

mspan 供应链

mcache 的 mspan 数量并不总是充足的，当供不应求的时候，mcache 会从 mcentral 再次申请更多的 mspan，同样的，如果 mcentral 的 mspan 数量也不够的话，mcentral 也会向它的上级 mheap 申请 mspan。再极端一点，如果 mheap 里的 mspan 也无法满足程序的内存申请，那该怎么办？
那就没办法啦，mheap 只能厚着脸皮跟操作系统这个老大哥申请了。
以上的供应流程，只适用于内存块小于 64KB 的场景，原因在于Go 没法使用工作线程的本地缓存mcache和全局中心缓存 mcentral 上管理超过 64KB 的内存分配，所以对于那些超过 64KB 的内存申请，会直接从堆上(mheap)上分配对应的数量的内存页（每页大小是 8KB）给程序。

3.2 什么是堆内存和栈内存？

根据内存管理（分配和回收）方式的不同，可以将内存分为 堆内存 和 栈内存。
那么他们有什么区别呢？
堆内存：由内存分配器和垃圾收集器负责回收
栈内存：由编译器自动进行分配和释放
一个程序运行过程中，也许会有多个栈内存，但肯定只会有一个堆内存。
每个栈内存都是由线程或者协程独立占有，因此从栈中分配内存不需要加锁，并且栈内存在函数结束后会自动回收，性能相对堆内存好要高。
而堆内存呢？由于多个线程或者协程都有可能同时从堆中申请内存，因此在堆中申请内存需要加锁，避免造成冲突，并且堆内存在函数结束后，需要 GC （垃圾回收）的介入参与，如果有大量的 GC 操作，将会吏程序性能下降得历害。

3.3 逃逸分析的必要性

由此可以看出，为了提高程序的性能，应当尽量减少内存在堆上分配，这样就能减少 GC 的压力。
在判断一个变量是在堆上分配内存还是在栈上分配内存，虽然已经有前人已经总结了一些规律，但依靠程序员能够在编码的时候时刻去注意这个问题，对程序员的要求相当之高。
好在 Go 的编译器，也开放了逃逸分析的功能，使用逃逸分析，可以直接检测出你程序员所有分配在堆上的变量（这种现象，即是逃逸）。
方法是执行如下命令

go build -gcflags '-m -l' demo.go

# 或者再加个 -m 查看更详细信息
go build -gcflags '-m -m -l' demo.go

3.4 内存分配位置的规律

如果逃逸分析工具，其实人工也可以判断到底有哪些变量是分配在堆上的。
那么这些规律是什么呢？
经过总结，主要有如下四种情况

根据变量的使用范围
根据变量类型是否确定
根据变量的占用大小
根据变量长度是否确定

接下来我们一个一个分析验证

根据变量的使用范围

当你进行编译的时候，编译器会做逃逸分析(escape analysis)，当发现一个变量的使用范围仅在函数中，那么可以在栈上为它分配内存。
比如下边这个例子

func foo() int {
    v := 1024
    return v
}

func main() {
    m := foo()
    fmt.Println(m)
}

我们可以通过 go build -gcflags '-m -l' demo.go 来查看逃逸分析的结果，其中 -m 是打印逃逸分析的信息，-l 则是禁止内联优化。
从分析的结果我们并没有看到任何关于 v 变量的逃逸说明，说明其并没有逃逸，它是分配在栈上的。

$ go build -gcflags '-m -l' demo.go
# command-line-arguments
./demo.go:12:13: ... argument does not escape
./demo.go:12:13: m escapes to heap

而如果该变量还需要在函数范围之外使用，如果还在栈上分配，那么当函数返回的时候，该变量指向的内存空间就会被回收，程序势必会报错，因此对于这种变量只能在堆上分配。
比如下边这个例子，返回的是指针

func foo() *int {
    v := 1024
    return &v
}

func main() {
    m := foo()
    fmt.Println(*m) // 1024
}

从逃逸分析的结果中可以看到 moved to heap: v ，v 变量是从堆上分配的内存，和上面的场景有着明显的区别。

$ go build -gcflags '-m -l' demo.go
# command-line-arguments
./demo.go:6:2: moved to heap: v
./demo.go:12:13: ... argument does not escape
./demo.go:12:14: *m escapes to heap

除了返回指针之外，还有其他的几种情况也可归为一类：
第一种情况：返回任意引用型的变量：Slice 和 Map

func foo() []int {
    a := []int{1,2,3}
    return a
}

func main() {
    b := foo()
    fmt.Println(b)
}

逃逸分析结果

$ go build -gcflags '-m -l' demo.go
# command-line-arguments
./demo.go:6:12: []int literal escapes to heap
./demo.go:12:13: ... argument does not escape
./demo.go:12:13: b escapes to heap

第二种情况：在闭包函数中使用外部变量

func Increase() func() int {
    n := 0
    return func() int {
        n++
        return n
    }
}

func main() {
    in := Increase()
    fmt.Println(in()) // 1
    fmt.Println(in()) // 2
}

逃逸分析结果

$ go build -gcflags '-m -l' demo.go
# command-line-arguments
./demo.go:6:2: moved to heap: n
./demo.go:7:9: func literal escapes to heap
./demo.go:15:13: ... argument does not escape
./demo.go:15:16: in() escapes to heap

根据变量类型是否确定

在上边例子中，也许你发现了，所有编译输出的最后一行中都是 m escapes to heap 。
奇怪了，为什么 m 会逃逸到堆上？
其实就是因为我们调用了 fmt.Println() 函数，它的定义如下

func Println(a ...interface{}) (n int, err error) {
    return Fprintln(os.Stdout, a...)
}

可见其接收的参数类型是 interface{} ，对于这种编译期不能确定其参数的具体类型，编译器会将其分配于堆上。

根据变量的占用大小

最开始的时候，就介绍到，以 64KB 为分界线，我们将内存块分为小内存块和大内存块。
小内存块走常规的 mspan 供应链申请，而大内存块则需要直接向 mheap，在堆区申请。
以下的例子来说明

func foo() {
    nums1 := make([]int, 8191) // < 64KB
    for i := 0; i < 8191; i++ {
        nums1[i] = i
    }
}

func bar() {
    nums2 := make([]int, 8192) // = 64KB
    for i := 0; i < 8192; i++ {
        nums2[i] = i
    }
}

给 -gcflags 多加个 -m 可以看到更详细的逃逸分析的结果

$ go build -gcflags '-m -l' demo.go
# command-line-arguments
./demo.go:5:15: make([]int, 8191) does not escape
./demo.go:12:15: make([]int, 8192) escapes to heap

那为什么是 64 KB 呢？
我只能说是试出来的（8191刚好不逃逸，8192刚好逃逸），网上有很多文章千篇一律的说和 ulimit -a 中的 stack size 有关，但经过了解这个值表示的是系统栈的最大限制是 8192 KB，刚好是 8M。

$ ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192

我个人实在无法理解这个 8192 （8M）和 64 KB 是如何对应上的，如果有朋友知道，还请指教一下。

根据变量长度是否确定

由于逃逸分析是在编译期就运行的，而不是在运行时运行的。因此避免有一些不定长的变量可能会很大，而在栈上分配内存失败，Go 会选择把这些变量统一在堆上申请内存，这是一种可以理解的保险的做法。

func foo() {
    length := 10
    arr := make([]int, 0 ,length)  // 由于容量是变量，因此不确定，因此在堆上申请
}

func bar() {
    arr := make([]int, 0 ,10)  // 由于容量是常量，因此是确定的，因此在栈上申请
}

4 一文掌握 Go 泛型的使用

泛型，可以说是 Go 这几年来最具争议的功能，应该没人有意见吧？
其实 Go 在早前的 Beta 版本中，就提供了对泛型的支持，但还不够成熟，直到 Go 1.18 才是支持泛型的正式版本。
下面我学习了官方关于泛型的文档之后，将学习的心得总结分享给大家

4.1 非泛型的写法

现有一个 map ，我们需要实现一个函数，来遍历该 map 然后将 value 的值全部相加并返回。
而由于这个 map 的 value 可以是任意类型的数值，比如 int64, float64
于是为了接收不同类型的 map，我们就得定义多个函数，这些函数 除了入参类型及返回值类型不同外，没有任何不同

func SumInts(m map[string]int64) int64 {
    var s int64
    for _, v := range m {
        s += v
    }
    return s
}

func SumFloats(m map[string]float64) float64 {
    var s float64
    for _, v := range m {
        s += v
    }
    return s
}

4.2 用泛型的写法

若是以代码行数来定义工作量，我可不希望泛型的出现，但从另一方面来讲，这种代码横看竖看都让人非常不舒服。
同样的需求，在有了泛型之后，写法就变得简洁许多

func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V {
    var s V
    for _, v := range m {
        s += v
    }
    return s
}

在这个函数中，它比常规的函数多了 [K comparable, V int64 | float64] 这么一段代码，这便是 泛型新增的语法，位于函数名与形参之间。
我来解释下这段 “代码”：

K 和 V 你可以理解为类型别名，在中括号之间进行定义，作用域也只在此函数内，可以在形参、函数主体、返回值类型里使用
comparable 是 Go 语言预声明的类型，是那些可以比较（可哈希）的类型的集合，通常用于定义 map 里的 key 类型
int64 | float64 意思是 V 可以是 int64 或 float64 中的任意一个
map[K]V 就是使用了 K 和 V 这两个别名类型的 map

有了泛型函数的定义，那如何调用该函数？
调用方式还是跟普通函数一样，只是在函数名和实参之间，可以再次使用中括号来指明上面的 K 和 V 分别是什么类型？

func main() {
    // Initialize a map for the integer values
    ints := map[string]int64{
        "first": 34,
        "second": 12,
    }

    // Initialize a map for the float values
    floats := map[string]float64{
        "first": 35.98,
        "second": 26.99,
    }

    fmt.Printf("Generic Sums: %v and %v\n",
        SumIntsOrFloats[string, int64](ints),
        SumIntsOrFloats[string, float64](floats),
    )
}

最后使用 go run 去跑一下，结果正常输出

4.3 简化泛型写法

1 类型自动推导

在调用大部分的泛型函数时，中括号里的内容，是可以省略不写的，而这个不写的前提是，编译器有办法根据你的实参及形参来自动推导出泛型函数中别名类型对应的类型（在上例中就是 K 和 V）。
而在上面的例子中，刚好是满足的，于是泛型函数的调用就可以简化成这样

fmt.Printf("Generic Sums: %v and %v\n",
    SumIntsOrFloats(ints),
    SumIntsOrFloats(floats),
)

2 使用类型别名

上面的 V 使用 int64 | float64 这样的写法来表示 V 可以是其中的任意一种类型。
若这个 V 用得比较多呢？可以考虑用 type 来事先定义别名

type Number interface {
    int64 | float64
}

然后泛型函数的定义就可以简化成下面这样

func SumNumbers[K comparable, V Number](m map[K]V) V {
    var s V
    for _, v := range m {
        s += v
    }
    return s
}

4.4 写在最后

在去年，其实就通过其他人的文章中事先了解到了 Go 泛型的写法，给我的第一印象是，函数的定义变得更复杂，可读性也越来越差，一时间我也有点难以接受。
不过经过自己试用后，情况倒没有我想象的那么糟糕！新版没有改变原有函数的定义与调用，若你没有使用泛型，那么有没有泛型对你来说没有区别。
但即使你有想法需要用到泛型，我也相信这种的不适感会在时间的流逝中慢慢淡化。

posted @ 2024-03-14 23:21 liuyang9643 阅读(3) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

liuyang9643