堆与栈

什么是仓库?

在计算机范畴中，仓库是非常重要的概念，数据结构中有仓库，内存分配中也有仓库，两者在界说和用途上虽不同，但也有些许相关，比方内存分配中栈的压栈和出栈操作，类似于数据结构中的栈的操作办法。

数据结构中的仓库

数据结构是将数据按序摆放的一种办法，在数据结构的仓库是两种数据结构：堆与栈，界说如何将数据按序进行存储和取出，是软件程序安排编排数据的手法。需求将内存分配中的仓库差异开，本文也主要探求内存分配中的仓库。

内存分配中的仓库

软件程序在运转进程中，必不可少的会运用变量、函数（也是一种变量）和数据，变量和数据在内存中存储的方位可分为：栈区和堆区，一般由 C 或许C++编译的程序占用的内存可分为：

• 栈区（Stack）
• 堆区（Heap）
• 全局区（静态区 Static）
• 常量区
• 程序代码区

软件程序中的数据和变量都会被分配到程序所在的虚拟内存空间中，内存空间包含两个重要区域：栈区（Stack）和堆区（Heap）， 下面针对Golang言语分配的栈空间和堆空间进行讨论。

栈（Stack）

每个函数都有自己独立的栈空间，函数的调用参数、回来值以及局部变量大都被分配到该函数的栈空间中， 这部分内存由编译器进行办理，编译时确认分配内存的巨细。栈空间有特定的结构和寻址办法，所以寻址十分迅速、开支小，只需求2条 CPU 指令，即压栈出栈PUSH和RELEASE，由于函数栈内存的巨细在编译时确认， 所以当局部变量数据太大就会产生栈溢出（Stack Overflow）。当函数履行结束后， 函数的栈空间被收回， 无需手动去开释。

差异于堆空间，经过malloc出来的内存，函数履行结束后需求“手动”开释，“手动”开释在有废物收回的言语中，表现为废物收回体系，比方 Golang 言语的 GC 体系，GC 体系经过符号等手法，识别出需求收回的空间。

堆（Heap）

堆空间没有特定的结构，也没有固定的巨细，能够动态进行分配和调整，所以内存占用较大的局部变量会放在堆空间上，在编译时不知道该分配多少巨细的变量，在运转时也会分配到堆上，在堆上分配内存开支比在栈上大，并且堆上分配的内存需求手动开释，关于 Golang 这种有 GC 机制的言语， 也会增加 GC 压力， 也容易造成内存碎片。

题外话：

之前开发 iOS 时，体系的 OC (Objective-C)言语，之前选用 MRC（手动办理内存）的办法办理内存，符号变量选用引证计数的办法，变量被引证一次则引证计数加 1，削减引证一次则引证计数减一，直到引证计数减到 0，符号开释该变量的内存，+1 和 -1 操作有必要配对，不然导致内存走漏，各种野指针 Crash。后来 OC && Swift 逐步的选用 ARC （自动引证计数）办理办法，即由体系去办理变量的引证计数，无需开发者去手动操作 +1 和 -1 操作，极大的进步了代码质量和下降了内存走漏的危险， 但一起也增加了体系开支。

Golang 言语也是同样的机制，由 GC 体系去办理堆上的内存，仅仅 GC 算法不同，选用三色符号法，GC 的好处在于不必手动去办理堆上的内存，可是一起增加了体系的开支，或许会产生微秒级 STW。

Note：栈是线程等级的，堆是进程等级的。

内存逃逸

什么是内存逃逸?

一言以蔽之, 本该分配到函数栈空间的变量，被分配到了堆空间，称为内存逃逸；过多的内存逃逸会导致 GC 压力变大，堆空间内存碎片化。

内存逃逸战略

在 Golang 言语中，变量不能显现地指定分配到栈空间仍是堆空间，比方：new,make等关键字，不能确认分配在栈空间仍是堆空间，那咱们怎么知道变量是分配到栈上仍是堆上呢？从下面官方的回复可知：官方让开发者无需关心变量是分配在栈上仍是堆上，可是为了写出高质量代码和定位问题，仍是有必要了解 Golang 底层内存办理的逻辑。

引证自官方回复：golang.org/doc/faq#sta…

How do I know whether a variable is allocated on the heap or the stack?

From a correctness standpoint, you don’t need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.

The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function’s stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.

In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.

大致的意思标明一个原则：只要局部变量不能证明在函数结束后不能被引证，那么就分配到堆上。换句话说，假如局部变量被其他函数所捕获，那么就被分配到堆上。

由上可知，根据栈空间的特功能够知道，函数栈帧的巨细是有限的且在编译时就现已确认，假如在编译时无法确认变量巨细或许变量过大，在 runtime 运转时分配到堆上。

逃逸剖析（Escape analysis）

在程序编译阶段根据程序代码中的数据流，对代码中哪些变量需求在栈空间上分配，哪些变量需求在堆空间上分配，进行静态剖析。一个抱负的逃逸剖析算法，能将开发者认为需求分配在栈空间上的变量尽或许保留在栈空间上，尽或许少的“逃逸”到堆空间上。抱负过于丰满，实践却很骨感，言语状况不同，言语版别不同，逃逸算法的精确度以及实践优化状况也不尽相同。关于开发者而言，只需把握逃逸剖析东西以及逃逸剖析的方针即可。

Golang 言语的逃逸剖析算法有两个版别，go1.13.6 darwin/amd64之后的版别由Matthew Dempsky这位老哥重写了，在源码的src/cmd/compile/internal/gc/escape.go 文件中，并有详整的注释。感兴趣能够拜读，虽只有一千多行代码，且有完好的算法说明和代码注释，但仍然“打脑壳”。

源文件注释了 Golang 言语逃逸剖析算法的原理，是内存逃逸的指导思想，有两个基本的不变性：

The two key invariants we have to ensure are:

(1) pointers to stack objects cannot be stored in the heap

(2) pointers to a stack object cannot outlive that object (e.g., because the declaring function returned and destroyed the object’s stack frame, or its space isreused across loop iterations for logically distinct variables).

• 指向栈目标的指针不能存储在堆中
• 指向栈目标的指针不能超越该栈目标的存活期（即指针不能在栈目标被毁掉后仍旧存活）

逃逸剖析算法的大致原理和进程注释中也有说明， 大致进程:

1. Golang 编译器解析 Golang 源文件后获取笼统语法树（AST）。
2. 构建有向加权图， 遍历该有向加权图寻觅或许违反上述两个不变性的赋值途径， 假如一个变量的地址是储存在堆或许其他或许会超越它存活期的当地， 则该变量就会被符号为需求在堆上分配。
3. 剖析函数之间的数据时，逃逸剖析算法记录每个函数的数据流等手法，详细算法可移步至源码。

咱们虽无法经过new,make或许字面量的办法显现地指定变量的分配方位，但能够经过逃逸剖析了解变量被分配到栈空间仍是堆空间，能够针对性地进步热门接口的响应、优化内存进步 GC 功率防止OOM等。日常开发中也无需详细了解逃逸剖析算法的作业原理，只需合作运用 Golang 的东西链，即可运用逃逸剖析算法进行逃逸剖析。

剖析东西

运用编译东西

经过编译东西检查详细的逃逸剖析进程，指令：go build -gcflags '-m -l' xxxx.go

编译参数（-gcflags）：

• -N: 制止编译优化
• -l: 制止内联
• -m: 逃逸剖析
• -benchmem:压测时打印内存分配统计

例如:main函数内声明局部变量badBoy，局部变量未被外部捕获，理论上会在函数栈上分配。

package main
type Person struct {
    Name   string
    EnName string
}
func main() {
    badBoy := &Person{
        Name: "法外狂徒张三",
        EnName: "ZhangSan",
    }
    _ = badBoy
}

输入指令：go build -gcflags '-m -l' main.go，传入-l封闭inline，屏蔽掉inline对终究生成代码的影响。

从 Terminal 的输出能够很轻易的分辨出变量是否逃逸到堆上，有个当地需求注意, 输出显现 main.go 源文件的 11 行 &Person 类型的变量没有产生逃逸， 其实struct类型在编译之前会压缩成一行：badBoy := &Person{Name: "法外狂徒张三", EnName: "ZhangSan"}

// ============= Command && Output ==================
Command :
go build -gcflags '-m -l' main.go
Output :
# command-line-arguments
./main.go:11:11: main &Person literal does not escape

运用汇编

经过反编译指令检查go tool compile -S xxxx.go，可愈加底层愈加精确地判断目标是否逃逸

例如: 和上面的代码相同， 仅仅增加一行fmt.Println

package main
import "fmt"
type Person struct {
    Name   string
    EnName string
}
func main() {
    badBoy := &Person{
        Name:   "法外狂徒张三",
        EnName: "ZhangSan",
    }
    fmt.Println(badBoy)
}

指令行：go tool compile -S main.go | grep xxxx

检查某一行的汇编，能直接定位到源代码某一行反编译后的汇编代码，有针对性的定位目标是否逃逸

// ============= Command && Output ==================
Command: 
go tool compile -S main.go | grep main.go:15
Output:                                                                                                                    czp-bytedance@MacBook-Pro
0x0071 00113 (main.go:15)       PCDATA  $0, $2
0x0071 00113 (main.go:15)       PCDATA  , 
0x0071 00113 (main.go:15)       XORPS   X0, X0
0x0074 00116 (main.go:15)       MOVUPS  X0, ""..autotmp_14+64(SP)
0x0079 00121 (main.go:15)       PCDATA  $0, $3
0x0079 00121 (main.go:15)       LEAQ    type.*"".Person(SB), AX
0x0080 00128 (main.go:15)       PCDATA  $0, $2
0x0080 00128 (main.go:15)       MOVQ    AX, ""..autotmp_14+64(SP)
0x0085 00133 (main.go:15)       PCDATA  $0, $0
0x0085 00133 (main.go:15)       MOVQ    DI, ""..autotmp_14+72(SP)
0x00e5 00229 (main.go:15)       MOVQ    DX, DI

指令行：go tool compile -S main.go | grep new

在反编译的汇编代码中查找new关键字， 能够看到汇编中呈现runtime.newobject， 说明在运转时在堆上动态请求的变量，一般状况下， 咱们选用编译东西就能明晰的看出哪些变量产生了逃逸， 汇编愈加底层。

// ============= Command && Output ==================
Command: 
go tool compile -S main.go | grep new
Output: 
0x002c 00044 (main.go:13)       CALL    runtime.newobject(SB)
rel 45+4 t=8 runtime.newobject+0

Note: 上述两段示例代码，逻辑上没有任何不同，仅仅增加了 fmt.Println 打印的代码，为何局部变量就产生逃逸了呢？下面就来看看有咱们日常开发中，常见的产生逃逸的场景。

逃逸场景

1. 函数回来局部变量指针

回来局部变量的指针, 在函数之外引证该局部变量的地址, 根据上面的剖析内存逃逸战略，两个不变性之一“在编译时能发现，指针不能在栈目标被毁掉后仍旧存活” ， 当外部没有引证局部变量地址时， 局部变量不会产生逃逸。

例如：buildPerson函数回来局部变量的指针，在main函数中引证局部变量指针产生内存逃逸。

package main
type Person struct {
    Name   string
    EnName string
}
func buildPerson(name, enName string) *Person {
    return &Person{
        Name:   name,
        EnName: enName,
    }
}
func main() {
    badBoy := buildPerson("法外狂徒张三", "ZhangSan")
    badBoy.EnName = "ZhangSan"
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:8:18: leaking param: name
./main.go:8:24: leaking param: enName
./main.go:11:3: &Person literal escapes to heap // 产生逃逸，第 11 行其实是第 9 行

2. 动态反射 interface{} 变量

经过运用汇编东西，反编译后能够看到 fmt.Println 变量后，变量产生了逃逸，忽然想到之前看的一篇文章(用 Go struct 不能犯的一个低级错误！)，文章中说到体系函数，比方：fmt.Println之类的底层体系函数，完成逻辑会根据 interface{} 做反射，经过 reflect.TypeOf(arg).Kind() 获取接口目标的底层数据类型，创立详细类型目标时，会产生内存逃逸。由于 interface{} 的变量，编译时无法确认变量类型以及请求空间巨细，所以不能在栈空间上请求内存，需求在 runtime 时动态请求，理所应当地产生内存逃逸。

例如：fmt.Println打印局部变量，产生内存逃逸。

package main
import "fmt"
type Person struct {
    Name   string
    EnName string
}
func main() {
    badBoy := &Person{
        Name:   "法外狂徒张三",
        EnName: "ZhangSan",
    }
    fmt.Println(badBoy)
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:13:11: &Person literal escapes to heap
./main.go:15:13: main ... argument does not escape
./main.go:15:13: badBoy escapes to heap

3. 请求栈空间过大

栈空间巨细是有限的，假如编译时发现局部变量请求的空间过大，则会产生内存逃逸，在堆空间上给大变量分配内存。

例如：main函数中请求大内存变量，产生内存逃逸。

package main
func main() {
    num := make([]int, 0, 10000)
    _ = num
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:4:13: make([]int, 0, 10000) escapes to heap

经过测验，num := make([]int, 0, 8192)时刚好产生内存逃逸。在 64 位机上int类型为 8B，即 8192 * 8B = 64KB

package main
func main() {
    num := make([]int, 0, 8191)
    _ = num
}
# command-line-arguments
./main.go:4:13: main make([]int, 0, 8191) does not escape
// ===========================================
package main
func main() {
    num := make([]int, 0, 8192)
    _ = num
}
# command-line-arguments
./main.go:4:13: make([]int, 0, 8192) escapes to heap

再进一步测验， slice， map 这类可扩容的类型和 int 之类的根底类型是否一致呢？多大的容量会产生逃逸呢？

例如：可扩容类型变量，Slice 指定 8192Byte（64KB）的预估容量（Cap），刚好产生内存逃逸；根底类型变量，10MB 巨细产生内存逃逸。

package main
type Person struct {
    Name   [4]byte
    EnName [4]byte
}
func main() {
    // 8B * 8192 = 64KB
    testSlice := make([]int, 0, 8192)
    testPersonSlice := make([]Person, 0, 8192)
    _ = testSlice
    _ = testPersonSlice
    // 10M
    var testNum [1024*1024*1.25]int
    _ = testNum
    var testNum2 [1024*1024*1.25 + 1]int
    _ = testNum2
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:19:6: moved to heap: testNum2
./main.go:10:19: make([]int, 0, 8192) escapes to heap
./main.go:11:25: make([]Person, 0, 8192) escapes to heap

由上可知，请求大局部变量时，根底类型变量如 int 最大可在栈上请求 <10MB，slice 之类可扩容的类型，可在栈上请求 <64KB 的内存空间。这种分配战略，猜想或许跟 Go 内存办理，mspan 的页巨细为 8KB 有关系。

Note：在上述测验中，slice 的元素是根底变量，假如 slice 的元素是目标指针又是如何进行内存分配呢？

4. 切片变量本身和元素的逃逸

1. 未指定 slice 的 length 和 cap 时，slice 本身未产生逃逸，slice 的元素产生了逃逸。由于 slice 会动态扩容，编译器不知道容量巨细，无法提早在栈空间分配内存，扩容后 slice 的元素或许会被分配到堆空间，所以 slice 容器本身也不能被分配到栈空间。

package main
type Person struct {
    Name   string
    EnName string
}
func main() {
    var personList []*Person
    p1 := &Person{Name: "test1"}
    p2 := &Person{Name: "test2"}
    personList = append(personList, p1)
    personList = append(personList, p2)
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:11:22: &Person literal escapes to heap
./main.go:12:22: &Person literal escapes to heap

2. 只指定 slice 的长度即 array, 数组本身和元素均在栈上分配内存，均未产生逃逸

package main
type Person struct {
    Name   string
    EnName string
}
func main() {
    var personList [3]*Person
    p1 := &Person{Name: "test1"}
    p2 := &Person{Name: "test2"}
    p3 := &Person{Name: "test3"}
    personList[0] = p1
    personList[1] = p2
    personList[2] = p3
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:11:22: main &Person literal does not escape
./main.go:12:22: main &Person literal does not escape
./main.go:13:22: main &Person literal does not escape

5. 闭包捕获变量

闭包其本质便是函数，当捕获其他函数的局部变量后，该局部变量会产生内存逃逸，由于闭包有或许是推迟函数，会晚于当时函数履行结束，假如当时函数内的局部变量分配在栈空间， 那么闭包在履行时就无法找到该变量，呈现野指针，所以当闭包捕获局部变量时，该局部变量一定会产生内存逃逸。

例如： 闭包捕获局部变量指针，该指针被分配到堆空间，根据不变性第二点，所指目标也被分配到堆空间。

package main
type Person struct {
    Name   string
    EnName string
}
func getPersonNameFunc(p *Person) func() string {
    return func() string {
        return p.Name
    }
}
func main() {
    badBoy := &Person{Name: "法外狂徒张三", EnName: "ZhangSan"}
    goodBoy := &Person{Name: "李四", EnName: "LiSi"}
    defer func() {
        _ = badBoy
    }()
    getPersonNameFunc(goodBoy)
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:8:24: leaking param: p
./main.go:9:9: func literal escapes to heap
./main.go:16:44: main &Person literal does not escape
./main.go:17:45: &Person literal escapes to heap
./main.go:19:8: main func literal does not escape

从上能够看出，goodBoy被闭包捕获，badBoy被 defer 声明的闭包捕获，可是goodBoy产生了内存逃逸，badBoy并没有产生内存逃逸，这是由于捕获badBoy的闭包是defer声明的，该闭包在函数return后履行，即该闭包履行结束，函数才真正履行结束， 所以履行defer闭包时，不会开释函数栈上的内存，所以编译时在静态剖析数据流后，badBoy被分配到栈上。

6. 发送指针或带有指针的值到 channel 中

Golang 中经典的规划：不要经过同享内存的办法进行通讯，而是应该经过通讯的办法同享内存。

然后诞生了 channel 管道规划，完成 goroutine 之间同享内存数据，所以往 channel 中发送内存数据时，编译器不知道哪个 goroutine 何时会从 channel 中读出数据，所以不会分配到 goroutine 的栈空间，再者栈空间是 goroutine 的独立空间，同享内存数据也应该分配到堆空间才能完成同享。

例如：发送值目标到 channel 会拷贝，不会产生内存逃逸；发送目标指针到 channel 被捕获，产生内存逃逸，指针所指目标在堆空间分配。

package main
type Person struct {
    Name   string
    EnName string
}
func main() {
    badBoy := Person{Name: "法外狂徒张三", EnName: "ZhangSan"}
    goodBoy := &Person{Name: "李四", EnName: "LiSi"}
    // 发送值目标到 channel
    valueChannel := make(chan Person, 1)
    valueChannel <- badBoy
    // 发送目标指针到 channel
    pointerChannel := make(chan *Person, 1)
    pointerChannel <- goodBoy
    go func() {
        _, _ = <-valueChannel, <-pointerChannel
    }()
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:10:45: &Person literal escapes to heap
./main.go:20:5: func literal escapes to heap

思考：

• 发送 slice 到 channel，会产生内存逃逸吗？
• 发送 array 到 channel，会产生内存逃逸吗？
• 发送 slice 到 channel，元素为值目标时，容器本身产生了内存逃逸，由于元素是值目标，产生了拷贝，本来的局部变量未产生内存逃逸；元素为指针目标时，容器本身和元素均产生内存逃逸。

package main
type Person struct {
    Name   string
    EnName string
}
func main() {
    badBoy := Person{Name: "张三", EnName: "ZhangSan"}
    goodBoy := &Person{Name: "李四", EnName: "LiSi"}
    // 发送值目标 slice 到 channel
    valueChannel := make(chan []Person, 1)
    valueChannel <- []Person{badBoy}
    // 发送目标指针 slice 到 channel
    pointerChannel := make(chan []*Person, 1)
    pointerChannel <- []*Person{goodBoy}
    go func() {
        _, _ = <-valueChannel, <-pointerChannel
    }()
    _, _ = <-valueChannel, <-pointerChannel
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:10:45: &Person literal escapes to heap
./main.go:14:26: []Person literal escapes to heap
./main.go:18:29: []*Person literal escapes to heap
./main.go:20:5: func literal escapes to heap

• 发送 array 到 channel，元素为值目标时，容器和元素均未产生逃逸；元素为指针目标时，容器本身和元素均产生内存逃逸。

package main
type Person struct {
    Name   string
    EnName string
}
func main() {
    badBoy := Person{Name: "张三", EnName: "ZhangSan"}
    goodBoy := &Person{Name: "李四", EnName: "LiSi"}
    // 发送值目标 array 到 channel
    valueChannel := make(chan [1]Person, 1)
    valueChannel <- [1]Person{badBoy}
    // 发送目标指针 array 到 channel
    pointerChannel := make(chan [1]*Person, 1)
    pointerChannel <- [1]*Person{goodBoy}
    go func() {
        _, _ = <-valueChannel, <-pointerChannel
    }()
    _, _ = <-valueChannel, <-pointerChannel
}
// ============= Command && Output ==================
Command: 
go build -gcflags '-m -l' main.go
Output: 
# command-line-arguments
./main.go:10:45: &Person literal escapes to heap
./main.go:20:5: func literal escapes to heap

番外篇：当 channel element 大于 8192 Byte 时提示，不能大于 64KB。

// 发送值目标到 channel
valueChannel := make(chan [10086]Person, 1)
valueChannel <- [10086]Person{badBoy}
// 发送目标指针到 channel
pointerChannel := make(chan [10086]*Person, 1)
pointerChannel <- [10086]*Person{goodBoy}
# command-line-arguments
./main.go:13:22: channel element type too large (>64kB)
./main.go:17:24: channel element type too large (>64kB)

逃逸剖析的效果

1. 经过逃逸剖析能确认哪些变量分配到栈空间，哪些分配到堆空间，对空间需求 GC 体系收回资源，GC 体系会有微秒级的 STW，下降 GC 的压力能进步体系的运转功率。
2. 栈空间的分配比堆空间更快功能更好，关于热门数据分配到栈上能进步接口的响应。
3. 栈空间分配的内存，在函数履行结束后由体系收回资源，不需求 GC 体系参加，也不需求 GC 符号铲除，可下降内存的占用，削减 RSS （常驻内存资源集），下降体系产生 OOM 的危险。

逃逸剖析的总结

• 栈空间分配内存比堆空间分配内存有更高的功率，不同版别的 Golang 版别优化不同，本文根据go1.13.6 darwin/amd64进行探求。
• 逃逸剖析意图是决定内存分配地址是栈空间仍是堆空间，关于开发者不能显现经过new，make或许literal的办法指定分配空间。
• 逃逸剖析在编译阶段完成，可经过编译东西或许反编译生成汇编代码进行剖析，前者方便快捷，后者精确。
• 关于大局部变量、大内存, 运用容器类型：slice、map、 array 最好指明长度、分配到栈上功能最佳，针对明确会逃逸到堆上的变量，应该了解是否会被捕获产生循环引证导致无法 GC 的问题。
• Golang 体系提供的函数，底层办法在 runtime 时 reflect 类型和生成目标，会产生内存逃逸，所以事务代码中尽量少运用反射，一方面进步代码可读性，另一方面把“逃逸”机会留给底层办法。
• 日常开发中，无论分配到栈空间仍是堆空间，不必过度的关心，只需了解常见的逃逸场景，遇到 OOM 时有思路去排查再优化即可。

项目实践

问题布景

本次探究源于 Sup 服务内存逐步升高，偶发性 OOM，隔几天就需求原地升级，稳定性隐患较大，@凌硕豪 在群里抛出忧虑，咱们开端讨论呈现的原因。

从上能够剖分出：

1. 地址 node 没有成环，假如成环，接口 15s 超时并且内存应该直接暴涨，不是缓慢的上升。
2. GC 体系正常作业，没有压力。
3. 或许是 RSS 导致的，一向有块内存在堆空间无法得到开释，并且越来越多。

根据上述三点，猜想问题所在：堆空间内存一向在分配，不知道被谁引证着，导致无法开释。

那么就有两个问题：

1. 局部变量为何被分配到堆空间？
2. 什么当地一向引证着该局部变量，导致无法 GC？

经过pprof东西观察并定位到代码方位，经过以上剖析得出deepcopy.Copy办法会导致内存逃逸。

从代码逻辑看，deepcopy.Copy在 runtime 时会进行反射操作，导致cacheObject产生内存逃逸，cacheObject变量分配到堆空间，可是逃逸之后也会被 GC，到底在哪里被引证了呢？

本来在缓存框架中，创立缓存时，会被捕获且一向引证着，如下：

处理方案

1. @凌硕豪 去掉了 framework cache 中对 country 数据的租户阻隔，防止 cache 占用和租户数正相关。
2. @王军 去掉了剩余的一次 deepcopy 库的深拷贝。

处理结果

sup 内存基本稳定在 35%，pprof heap 中也没有 country cache 的占用，现在占用较多的是灰度 feature。

总结

逃逸剖析关于日常开发而言不可或缺，关于进步代码质量、下降接口延时、进步体系稳定性都有非常大的协助，有时犹如一把利器割开捆绑的口子，困难就方便的解决。

欢迎咱们指正！

参加咱们

咱们来自字节跳动飞书商业应用研发部(Lark Business Applications)，现在咱们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。咱们重视的产品范畴主要在企业经历办理软件上，包含飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 范畴体系，也包含飞书审批、OA、法务、财务、采购、差旅与报销等体系。欢迎各位参加咱们。

扫码发现职位&投递简历

官网投递：job.toutiao.com/s/FyL7DRg